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SECTION  1 
INTRODUCTION 


1.1  PURPOSE 

This  report  contains  the  results  of  the  processing  svstem  architecture  task 
performed  bv  5021  under  the  Basic  Avionic  Subsystem  Integration  Concept  i BASIC ) 
Architecture  Interdepartmental  Work  Agreement  iIDWAi  No.  45-7^-04.  Pro- 
vided herein  is  a definition  of  an  avionic  information  processing  svstem  architecture 
and  recommendations  for  implementing  a subset  of  this  architecture  in  the  BASIC 
laboratory.  This  recommended  architecture  can  be  classified  as  a distributed, 
multiple  processing  system.  It  was  derived  based  on  the  S-3A  operational  re- 
quirements employing  a structured  system  design  methodology.  The  S-3A  archi- 
tecture was  chosen  as  a baseline  since  it  typifies  avionic  information  processing 
requirements.  In  addition,  current  Navy  standards,  such  as  the  AYK-14  air- 
borne computer  and  1553  bus,  were  employed  to  the  greatest  possible  extent. 

One  of  the  major  objectives  was  to  provide  flexibility  so  that  the  architec- 
ture can  adapt  to  varying  configurations  as  dictated  by  new  or  changing  technolo- 
gies. Another  major  objective  was  to  provide  fault  tolerance  so  that  the  system 
can  recover  from  and  circumvent  failures.  These  objectives  were  included  in 
the  criteria  for  assessing  the  recommended  architecture.  The  modularity  as- 
pects of  the  architecture  permit  the  system  to  be  implemented  and  verified  in 
an  incremental  manner.  This  is  a major  benefit  made  possible  bv  structured 
design. 

1.2  APPROACH 

A structured  svstem  design  methodology  was  employed  as  a tool  in  arriving 
at  the  architecture  in  this  report.  The  general  procedure  followed  includes  per- 
forming a requirements  analysis,  defining  an  application  structure,  establishing 
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assessment  criteria,  and  mapping  the  application  to  hardware  and  software  re- 
quirements. The  contents  of  this  report,  therefore,  detail  the  application  of 
this  procedure  to  the  S-3A  requirements  and  other  rationale  employed  in  deriving 
a proposed  avionic  information  processing  system  architecture. 

1.3  SUMMARY 

This  report  initially  describes  the  steps  involved  in  the  svstem  design 
methodology  (Section  2).  Application  requirements  are  derived  in  Section  3 
by  examining  the  existing  S-3A  processing  system.  This  results  in  a functional 
partitioning  of  the  operational  program  into  decompositional  units.  Section  4 
establishes  a baseline  generic  structure  as  wrll  as  assessment  criteria  rela- 
tive to  flexibility,  fault  tolerance,  and  recovery.  Implementations  for  the  de- 
compositional units  are  developed  in  Section  5.  An  analysis  is  performed  and 
rationale  is  provided  for  the  definition  of  a proposed  architecture.  An  imple- 
mentation subset,  recommended  for  the  BASIC  laboratorv,  is  then  described 
in  Section  6,  based  on  demonstrable  assessment  criteria  as  previously  established. 


j 


1-2 

A 

- A 


r 


NADC-79161-40 
SECTION  2 

SYSTEM  DESIGN  METHODOLOGY 

This  section  describes  the  methodology  used  in  development  of  the  recom- 
mended architecture  for  the  BASIC  laboratory. 

2.  1 METHODOLOGY  DESCRIPTION 

The  methodology  used  to  derive  the  proposed  system  is  based  upon  the 
Avionic  Information  Processing  System  Design  Methodology  currently  being 
developed  by  Univac  under  NAVAIRDEVCEN  5021  direction.  This  methodology 
is  still  in  a preliminary,  qualitative  state,  but  quantifying  enhancements  will 
soon  be  made.  A full  description  can  be  found  in  Reference  1. 

The  methodology  of  designing  information  processing  systems  should  be  a 
structured  process  consisting  of  the  following  stages: 

a.  Determination  of  the  application  requirements 

b.  Decomposition  of  the  requirements  into  decompositional  elements  (DE'st 

c.  Association  of  the  DE’s  into  decompositional  units  (DU’si 

d.  Synthesis  of  a control  structure  relating  Dl"s  to  one  another 

e.  Implementation  selection  for  each  DU  in  hardware,  software,  or  firm- 
ware 

f.  Selection  of  hardware  components  and  software  languages ) 

g.  Composition  of  the  hardware  system 

h.  Mapping  of  software  and  firmware  DU's  onto  the  hardware 

i.  Simulation  of  the  system,  both  hardware  and  software 

In  each  stage,  there  is  a decision  matrix  which  has  columns  headed  by 
design  choices  available  to  the  designer  and  rows  listing  assessment  criteria 
appropriate  to  that  design  stage.  The  elements  of  the  matrix  are  either  ~,  0, 
or  -,  representing  a positive  choice,  neutral  choice,  or  negative  choice,  re- 
spectively. Frequently,  qualitative  comments  also  accompany  the  matrix  elements. 
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The  designer  adds  up  the  elements  in  each  column  (that  is,  design  choice)  and 
chooses  the  column  with  the  largest  net  positive  total.  As  stated  before,  this 
approach  is  currently  qualitative;  but  work  on  quantifying  the  methodology, 
that  is,  assigning  numerical  weights  to  the  elements,  will  begin  shortly. 

The  design  process  will  not  be  examined  in  more  detail.  The  first  stage  is 
the  determination  of  the  application  requirements.  This  consists  of  the  follow- 
ing steps:  (1)  determination  of  the  algorithms  that  are  to  be  done  by  each  sensor 
and  subsystem:  (2)  development  of  the  repetition  rates  and  the  precision  of  each 
algorithm;  (3)  definition  of  the  information  to  be  received  from  and  sent  to  each 


sensor,  display,  subsvstem,  and  peripheral;  and  (4)  the  specification  of  the 
required  data  rates  for  such  transmissions. 

The  next  two  steps,  application  decomposition  and  association  into  DU's, 
p involve  the  partitioning  of  the  requirements  into  the  smallest  practical  elements 

(DE'st,  which  are  then  combined  to  form  the  Dl"s.  The  forming  of  DU's  makes 

r 

use  ot  the  natural  association  of  certain  DE's  on  the  basis  of  shared  resources 
or  data  transmission  between  the  grouped  elements. 

The  fourth  stage,  svnthesis  of  a control  structure,  involves  determination 
of  the  control  dependencies  among  DU’s  and  the  relative  priorities  of  the  DU's. 

It  should  be  noted  here  that,  thus  far  in  the  design  procedure,  no  assumption 
. has  been  made  concerning  the  implementation  of  the  DU's.  Whether  they  will 

be  implemented  in  hardware,  software,  or  firmware  is  of  no  importance  in  the 
first  four  steps.  However,  in  the  fifth  stage,  each  DU  is  bound  to  a specific 
medium  of  implementation. 

The  sixth  and  seventh  stages  are  self-explanatory.  At  this  time,  the  hard- 
ware components  are  selected  and  configured  into  a system.  The  hardware 
can  consist  of  both  dedicated  hardware  logic  for  those  DU’s  implemented  in  hard- 
ware and  processors,  memories,  buses,  and  input  output  (I  O)  peripherals 
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for  performing  the  software-  and  firmware-implemented  DU's.  The  selection 
of  software  languageisi  and  support  software  also  occurs  during  the  sixth  stage. 

In  the  eighth  stage,  the  software  and  firmware  DU's  are  mapped  onto  the 
hardware  chosen  previously.  This  mapping  can  be  either  static,  dynamic,  or 
a hybrid  of  the  two.  An  example  of  the  latter  might  be  an  initial  static  alloca- 
tion of  tasks  to  various  processors  in  a distributed  system  plus  a dynamic  recon- 
figuration capability  in  case  of  a fault  in  a processor.  .Alternatively,  the  dynamic 
mapping  algorithms  can  also  be  considered  as  another  Dl'  and  could  be  handled 
in  the  earlier  stages.  This  issue  is  still  to  be  decided  in  the  final  methodology. 

In  the  ninth  stage,  the  entire  system,  both  hardware  and  software,  is  simu- 
lated. During  this  stage,  tradeoff  studies  can  be  made,  the  system  can  be  "fine- 
tuned,  " and  the  final  system  validated.  Should  the  simulation  studies  show  that 
modifications  must  be  made  in  the  svstem,  the  irethodologv  procedure  can  be 
re-entered  at  any  of  the  earlier  stages,  the  changes  made,  and  the  succeeding 
steps  repeated  with  the  new  inputs. 

2.2  APPLICATION  OF  METHODOLOGY  TO  BASIC 

The  application  requirements  for  the  BASIC  laboratory  were  assumed  to  be 
functionally  equivalent  to  those  of  the  S-3A  avionic  suite  less  some  of  the  sensor 
processing.  Obviously,  the  subsystems  to  be  used  in  fugure  platforms  will  differ 
from  those  in  the  S-3A;  but,  since  the  information  processing  requirements  for 
these  future  subsystems  are  not  clearly  defined  at  present,  it  was  decided  to 
use  the  S-3A  avionic  requirements  to  design  an  initial  baseline  svstem.  .As  the 
requirements  for  the  new  subsystems  become  available,  they  can  be  inserted  into 
the  first  stage  of  the  methodology,  and  a new  information  processing  system  can 
be  designed.  However,  if  the  initial  information  processing  system  architecture 
is  flexible  enough,  it  should  be  able  to  accommodate  the  changed  requirements. 
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In  applying  the  methodology  to  the  S-3A  requirements  for  the  BASIC  design, 
the  first  three  stages  of  the  methodology  were  followed  in  the  described  pro- 
cedure to  partition  the  requirements  into  DU's.  However,  in  the  fourth  through 
the  eighth  stages,  the  methodology  was  not  fully  utilized.  There  are  several 
reasons  for  this.  First,  the  methodology  is  still  qualitative  and  not  yet  fully 
developed.  Second,  it  was  assumed  that  all  algorithms  would  be  performed  in 
software  because  of  the  decision  that  the  BASIC  laboratory  should  not  be  involved 
at  this  time  with  special-purpose  hardware  or  firmware  logic;  rather,  the  labora- 
tory should  stress  the  development  of  a flexible,  expandable  system.  Third, 
processors  used  in  naval  aircraft  for  the  next  decade  will  almost  surely  be 
standard  minicomputers  (AN  AYK-14  or  successors)  and  possibly  standard  micro- 
processors inot  yet  chosen);  so  the  proposed  system  architecture  is  being  developed 
based  on  these  assumptions.  Finally,  the  advances  being  made  in  computer  tech- 
nology during  the  last  couple  of  rears  virtually  lead  a designer  to  choose  a 
distributed  hvbrid  architecture  because  of  the  increasing  disparity  in  hardware 
costs  versus  software  cost. 

The  last  step  in  the  methodology,  that  of  verification  via  simulation,  has  not 
yet  been  performed  for  the  recommended  architecture,  but  the  simulation  inputs  are 
are  presently  being  prepared  and  results  will  be  available  in  a later  supplement 
to  this  report. 
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SECTION  3 

REQUIREMENTS  ANALYSIS 


The  first  step  in  the  design  methodology  is  the  determination  of  application 
requirements.  This  section  derives  application  requirements,  in  terms  of 
implementation-independent  decompositional  units,  from  an  extensive  examina- 
tion of  the  existing  S-3A  processing  system. 

3. 1 EXISTING  S-3A  INFORMATION  PROCESSING  SYSTEM  ARCHITECTURE 

The  following  paragraphs  provide  a functional  overview  of  the  current  imple- 
mentation of  the  S-3A  information  processing  system  with  respect  to  hardware 
configuration,  operational  program,  interfaces,  and  executive  functions.  Al- 
though this  information  is  detailed  in  various  related  S-3A  documentation,  a 
summary  is  provided  here  for  reference.  This  system  has  been  used  as  a base- 
line for  development  of  the  BASIC  architecture. 

3.1.1  Hardware  Configuration 

The  S-3A  information  processing  system  hardware  is  based  on  the  AN/' 
AYK-10  general-purpose  digital  computer.  All  the  antisubmarine  warfare  ( ASW) 
tactical  processing  is  controlled  by  this  computer.  The  AN/AYK-10  has  two 
central  processors  which  communicate  with  two  32-K  memory  units  over  instruc- 
tion and  operand  buses.  In  addition,  two  I/O  controllers  conduct  and  direct  all 
I/O  traffic  between  I/O  devices  and  memory.  A block  diagram  of  the  S-3A  digital 
avionics  hardware  configuration  is  shown  in  Figure  3-1. 

3. 1.1.1  Central  Processor 

Each  central  processor  is  composed  of  a control  section  and  an  arithmetic 
section.  The  control  section  interprets  the  instruction,  carries  out  the  com- 
mands, and  directs  the  sequence  of  events  for  the  logical  execution  of  avionic 
programs  and  external  interrupts.  The  arithmetic  section  performs  the  arith- 
metic and  logic  functions  as  directed  by  the  control  section.  Each  processor 
operates  independently,  but  both  use  the  same  instruction  repertoire  consisting 
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of  arithmetic,  logical,  compare,  and  I/O  operations.  Additional  processor 
speed  is  attained  through  the  use  of  memory  overlap  and  a high  speed  shift 
matrix.  Memory  overlap  involves  retrieving  the  present  operand  from  one 
memory  and  the  next  instruction  from  another  memory  in  parallel  over  two 
different  memory  buses. 

3. 1.1.  2 Memory  Units 

Each  of  two  memory  units  provides  up  to  32,  718  36-bit  words  (32  data  plus 
4 parity).  Each  memory  contains  its  own  addressing  circuitry  which  allows  each 
unit  to  function  independently  while  servicing  six  different  users.  The  memory 
has  an  average  cycle  time  of  750  nanoseconds. 

3. 1.1.3  I/O  Controller 

The  I/O  controller  and  interface  unit  provide  the  control  logic  which  (1) 
directs  the  sequence  of  events  for  the  logical  execution  of  input  and  output  pro- 
grams and  (2)  conducts  the  transfer  of  data  between  I/O  devices  and  memory. 

The  I/O  controller  requires  only  a single  initiation  command  from  a processor 
to  initiate  an  I/O  command  program  (chain).  This  I/O  command  program  uses 
its  own  command  repertoire  in  controlling  I/O  operations,  and  it  has  direct 
memory  access  through  its  own  I/O  memory  bus.  The  AN/AYK-10  provides  a 
serial  I/O  interface  to  S-3A  avionics  in  which  some  channels  may  have  up  to 
seven  devices  multiplexed  together. 

3. 1. 1.  4 Avionic  Sensors/Subsvstems 

A list  of  the  avionic  devices,  their  nomenclature,  and  their  function  is 
presented  in  Table  3-1.  Each  device  is  connected  to  the  AN/AYK-10  via  a 
Manchester  serial  channel.  The  maximum  channel  data  rate  for  the  acoustic 
data  processors  (ADP's)  Numbers  1 and  2 is  150  K words  per  second.  The  maxi- 
mum data  rate  for  the  remaining  devices  is  100  K words  per  second.  Normally, 
these  peripherals  run  at  a small  percentage  of  their  maximum  data  rate. 
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TABLE  3-1.  S-3A  AVIONIC  SENSORS/SUBSYSTEMS 


NOMENCLATURE 

NAME 

FUNCTION 

ADP 

Acoustic  Data  Processor 

Provides  acoustic  sensor  data. 

MPD 

Multipurpose  Display 

Displays  sensor  and  tactical 
data  to  operators. 

RADAR 

Radar  Subsystem 

Locates  objects  by  receiving 
transmitted  RF  energy. 

INS 

Inertial  Navigation 
Subsystem 

Provides  aircraft  position, 
velocity,  and  heading. 

NDRC 

Navigation  Data  Repeater 
and  Converter 

Interfaces  with  other  naviga- 
tion subsystems  to  provide 
aircraft  position,  course, 
speed,  altitude,  and  guidance. 

SRS 

Sonobuoy  Reference 
Subsystem 

Provides  sonobuoy  position 
relative  to  aircraft. 

IXCOS 

Integrated  Control 
Subsystem 

Provides  data  entry  for 
aircraft  operators. 

RAAWS 

Radar  Altimeter  and 
Altitude  Warning 

Subsystem 

Provides  aircraft  altitude 
above  terrain. 

ESM 

Electronic  Surveillance 
Measurement  Sub  - 
systems 

Provide  target  information 
from  received  RADAR 
signal. 

AACS 

Aire  raft- Altimeter 
Computer  Set 

Provides  air  speed,  temper- 
ature, and  altitude. 

DGVS 

Doppler  Ground  Ve- 
locity Subsystem 

Provides  aircraft  velocity. 

T 
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TABLE  3-1.  S-3A  AVIONIC  SENSORS/SUBSYSTEMS  (Continued) 


NOMENCLATURE 

NAME 

FUNCTION 

AHRS 

Altitude  and  Heading 
Reference  Subsystem 

Provides  aircraft  roll,  pitch, 
and  heading. 

MAD 

Magnetic  Anomaly 

Detection 

Provides  target  information 
from  detecting  anomaly  in 
earth's  magnetic  fields. 

SESCOS 

Search  Stores  Control 
Subsystem 

Provides  for  the  release  of 
search  stores  (for  example, 
sonobuoys). 

COMM 

Communication  Sub- 
system 

Provides  for  both  voice  and 
tactical  communication  be- 
tween forces. 

FLIR 

F orward-Looking 

Infrared  Subsystem 

Provides  target  information 
for  received  infrared 

radiation. 

ATR 

Analog  Tape  Recorder 

Provides  for  recording  of 
audio,  acoustic,  MAD,  and 
digital  data  for  later 
playback. 

ARMCOS 

Armament  Control 
Subsystem 

Provides  control  for  weapon 
launching. 

DMTU 

Digital  Magnetic  Tape 

Unit 

Provides  for  system  loading 
and  operational  event 
recording. 

SRX 

Sonobuov  Receiver 
Subsystem 

Provides  for  signal  data  com- 
munication from  sonobuoys  to 
aircraft. 
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The  S-3A  operational  program  is  divided  into  functional  areas  called  sub- 
programs. A brief  description  of  each  subprogram  is  provided  in  the  following 
paragraphs. 

3.1.2. 1 Executive  Subprogram  (EXEC) 

The  EXEC  subprogram  provides  the  initialization,  scheduling,  input/output 
control,  error  processing,  and  system  recovery  for  the  rest  of  the  subprograms. 
A further  discussion  regarding  the  executive  functions  is  provided  in  paragraph 
3. 1.  4 of  this  document. 

3. 1.2.  2 Keyset  Processing  and  Control  (KEYPAC)  Subprogram 

The  KEYPAC  subprogram  provides  the  primary  man-machine  interface  for 
the  operational  system.  KEYPAC  obtains  control  via  the  EXEC  through  inter- 
rupts received  from  the  keysets  located  at  the  operator  stations.  Upon  receiving 
control,  KEYPAC  provides  for  (1)  keyset  mode  control,  (21  matrix  select  switch 
control,  (3)  switch  lighting,  (4)  keyset  hardware  monitoring,  and  (5)  initiating 
the  operator  specified  functions. 

3.1.2.  3 Display  Processing  and  Control  'DISPAC)  Subprogram 

The  DISPAC  subprogram  provides  for  the  visual  means  of  communicating 
information  from  the  various  avionic  subsystems  to  the  S-3A  crewmember  via 
the  multipurpose  displays  (MPD's).  In  this  function  DISPAC  will  (1)  display 
operator  alerts,  (2)  display  and  process  cues,  (31  display  and  process  tableaus, 
and  (4)  control  tactical  symbology. 

3.1.2.  4 Navigation  (NAVI  Subprogram 

The  NAV  subprogram  provides  navigation  parameters  to  other  subprograms. 
These  navigation  parameters  include  (11  the  aircraft  geographic  position,  (21  the 
correct  relative  buoy  positions,  (31  the  carrier  position,  and  (4)  other  operator 
navigational  aids. 
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3. 1.2.  5 Steering  Subprograms 

The  steering  program  provides  for  automatic  steering  of  the  aircraft.  The 
steering  subprogram  directs  the  aircraft  via  an  automatic  flight  C''~  *rol  system 
to  fly  to  or  orbit  an  operator  entered  fly-to  point. 

3. 1.2.  6 Search,  Localization,  Track,  and  Attack  (SLTA)  Subprogram 

The  SLTA  subprogram  provides  a collection  of  aids  which  allows  the  tactical 
coordinator  (TACCO)  to  correlate  tactical  information  available  to  him  so  he  can 
employ  the  aircraft  in  the  most  effective  way  to  accomplish  its  mission.  These 
aids  include  (1)  standard  ASW  flight  pattern  selections,  (2)  fix  and  track  gener- 
ation, and  (3)  target  tracking  algorithms. 

3. 1.  2.  7 Communication  Processing  and  Control  (COMPAC)  Subprogram 

The  C07.IPAC  subprogram  provides  communication  capabilities  with  other 
S-3A's  and  surface  ships.  The  COMP  AC  subprogram  111  configures,  monitors, 
and  maintains  the  communication  equipment,  (2)  participates  in  the  operational 
data  link  nets,  t3)  transmits  tactical  data  to  other  participating  units,  and  (4> 
passes  received  tactical  data  to  interested  subprograms. 

3. 1.  2.  8 Ballistic  Subprogram 

The  ballistic  subprogram  uses  weapon  or  search  stores  flight  character- 
istics in  order  to  locate  drop- and- splash  points  to  within  a 100-vard  (30.  4-meter) 
radius.  The  ballistic  subprogram  provides  (1)  weapon  fly-to  points,  (2)  weapon 
splash  points,  and  (3)  expendable  splash  points. 

3. 1.2.  9 Armament  Control  (ARMCO.V)  Subprogram 

The  ARMCOV  subprogram  provides  the  means  to  select,  arm,  and  release 
weapons  loaded  on  wing  pylons,  triple  ejector  racks,  and  bomb  bay  stations. 

The  ARMCO.V  subprogram  (1)  enters  weapon  fly-to  points  into  the  system,  (2) 
selects  weapons  for  release,  (3)  controls  the  release,  and  (4)  updates  weapon 
inventory. 
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3-1.2.10  Search  Stores  Control  (SESCON)  Subprogram 

The  SESCON  subprogram  provides  the  ability  to  select,  prepare,  designate, 
and  release  search  stores  from  sonobuoy  launch  chutes.  The  SESCON  subpro- 
gram (1)  enters  search  stores  fly-to  points  into  the  system,  (2)  selects  search 
stores  for  release,  (3)  controls  the  release,  (4)  updates  the  search  stores 
inventory,  and  (5)  allows  for  designating  a sonobuoy  currently  in  the  water. 

3. 1.  2. 11  Acoustic  Control  i ACC  ON)  Subprogram 

The  ACCON  subprogram  provides  the  man- machine  interface  for  controlling 
the  acoustic  data  processor  (A DP),  the  analog  tape  recorder  1ATR),  and  the 
sonobuoy  receiver  set  (SRX).  The  ACCON  subprogram  (1)  maintains  control 
of  ADP,  ATR,  SRX  input  and  output  operations,  (2)  controls  the  acoustic  dis- 
play modes,  (3)  controls  the  audio  headsets,  (4)  assigns  sonobuoy  receiver  fre- 
quencies, and  (5)  manages  acoustic  contacts. 

3.1.2.12  Passive  Acoustic  Classification  iPAC)  Subprogram 

The  PAC  subprogram  provides  a method  of  classifying  passive  acoustic 
signals  according  to  their  origin.  The  PAC  subprogram  (1)  edits  digitized 
acoustic  data,  (2)  alerts  operator  of  active  contacts,  13)  classifies  targets,  and 

(4)  manages  contact  data. 

3.1.2.13  Active  Acoustic  Control  (ACTIVE)  Subprogram 

The  ACTIVE  subprogram  provides  target  localization  by  controlling  and 
processing  the  echoes  from  a sonic  pulse  transmitted  by  an  active  sonobuoy. 

The  ACTIVE  subprogram  (1)  controls  different  active  modes,  (2)  controls  the 
sequence  of  pings,  (3)  analyzes  ping  returns,  (4)  manages  active  contact,  and 

(5)  allows  display  of  targets. 

3.1.2.14  Forward-Looking  Infrared  (FLIR)  Subprogram 

The  FLIR  subprogram  aids  the  operator  in  identifying  targets  by  controlling 
the  FLIR  subsystem.  The  FLIR  subprogram  11)  controls  automatic  FLER 
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tracking  of  fixed  geographic  positions,  (2)  controls  automatic  FLER  slewing, 

(3)  provides  for  entry  of  FLIR  fLxes,  and  (4)  allows  for  adjustment  of  FLER  field 
of  view,  polarity,  brightness,  and  contrast. 

3. 1.  2. 15  Magnetic  Anomaly  Detection  (MAD)  Subprogram 

The  MAD  subprogram  provides  the  capability  to  detect,  evaluate,  and 
record  anomalies  in  the  earth's  magnetic  field  due  to  the  presence  of  sub- 
marines. The  MAD  subprogram  (1)  displays  MAD  sensor  data  on  display,  (2) 
provides  for  automatic  signal  detection,  and  (3)  provides  for  entry  of  MAD 
contacts. 

3. 1.  2. 16  Radar  Processing  and  Control  (RADAR)  Subprogram 

The  RADAR  subprogram  provides  the  capability  to  detect,  classify,  local- 
ize, and  track  submarine  snorkels  and  surface  vessels  through  the  use  of  the 
RADAR  subsystem.  The  RADAR  subprogram  < 1)  selects  the  type  and  format 
of  the  radar  to  be  displayed,  (21  allows  for  adjustment  of  antenna  position, 
power  levels,  radar  mode,  persi stent  video  gain,  receiver  gain,  and  false 
alarm  rate,  (31  provides  for  entrv  of  RADAR  fixes,  and  i4i  provides  for  auto 
tracking  of  a selected  target. 

3.1.2.17  Electronic  Surveillance  Measures  t'ESMl  Subprogram 

The  ESM  subprogram  provides  the  capability  of  detecting,  localizing,  and 
classifying  intercepted  radar  transmissions.  The  ESM  subprogram  (11  displays 
selected  emitters,  (21  provides  for  the  entry  of  ESM  contacts,  (31  eliminates 
redundant  emitters,  (41  classifies  emitters,  and  (51  controls  the  scan  frequency 
bands. 

3.1.2.13  Data  Extraction  (DEP1  Subprogram 

The  DEP  subprogram  provides  for  the  recording  of  specific  tactical  events 
on  the  airborne  digital  magnetic  tape  unit  (DMTU). 
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3. 1.  2. 19  System  Common  Routine  Subprogram 

The  system  common  routine  subprogram  Is  a collection  of  common  routines 
available  for  direct  use  by  any  task  without  going  through  the  executive.  These 
routines  are  categorized  as  mathematical,  conversion,  and  user  routines.  One 
program  copy  of  each  common  routine  is  employed  for  all  users. 

3-1.2.20  In-Flight  Performance  Monitoring  (IFPM)  Subprogram 

The  EFPM  subprogram  is  designed  to  detect,  verify,  and  take  appropriate 
action  in  response  to  error  indications  from  the  S-3A  avionic  equipment  units. 
When  the  IFPM  determines  that  a subsystem  or  component  of  the  processing 
system  meets  a predefined  failure  criteria,  it  communicates  this  information 
to  the  executive,  which  alerts  the  operators  and  indicates  the  status  of  the  sub- 
system in  a system  status  tableau. 

3. 1.  3 Interfaces 

The  following  paragraphs  provide  a description  of  the  interfaces  which  enable 
the  operator,  software,  and  hardware  elements  of  the  system  to  interact. 

3. 1.  3. 1 (Operator 

The  S-3A  is  an  operator-oriented  system  with  crew  stations  consisting  of 
pilot,  copilot,  tactical  coordinator  (TACCO),  and  sensor  operator  (SENSO).  The 
S-3A  aircraft  crew  communicates  with  the  avionic  system  through  alphanumeric/ 
video  multipurpose  displays  (MPD's>  and  functionally  oriented  keyboards. 

3. 1.  3.  2 Software 

There  aie  three  basic  ways  that  elements  of  the  various  subprograms  inter- 
face with  one  another.  The  first  is  at  the  task  level  in  which  one  task  can  sched- 
ule another  through  the  executive.  The  second  occurs  when  a task  calls  on  a 
subroutine  (common  routine)  to  perform  some  function  with  parameters  passed  in 
the  computer  registers.  The  third  method  is  through  shared  data,  the  most 
common  being  the  system  common  data. 
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3. 1.3.  3 Hardware 

Chains  (programs)  of  I/O  controller  (IOC)  commands  direct  the  I/O  controller/ 
interface  to  initiate  communication  between  the  computer  and  the  various  S-3A 
peripheral  subsystems.  When  a task  requires  data  to  be  transferred  to  or  from 
a peripheral  device,  the  following  steps  are  performed: 

a.  A data  memory  area  (data  buffer)  is  set  up  which  either  contains  the 
data  to  be  transferred  or  the  storage  area  to  which  the  data  is  to  be 
sent. 

b.  The  subprogram  calls  on  the  EXEC  subprogram  to  initiate  an  IOC  pro- 
gram (chain). 

c.  The  EXEC  directs  the  IOC  to  initiate  this  specific  chain  by  passing  the 
channel  number  and  chain  address  to  the  IOC  over  the  central  processing 
unit  (CPU)  to  IOC  data  bus. 

d.  The  IOC  initiates  this  chain,  which  causes  data  words  to  be  trans- 
ferred between  the  peripheral  and  data  buffer.  This  data  transfer  is 
under  complete  control  of  the  IOC  chain;  thus,  the  CPU  is  free  to  do 
other  processing  while  the  data  transfer  is  in  process. 

e.  Upon  completion  of  the  transfer,  the  IOC  chain  usually  interrupts  the 
CPU  and  notifies  the  EXEC  of  the  completion.  The  EXEC  will  either 
notify  the  requesting  subprogram  or  a subprogram  interrupt  handler 
(IHX>  of  this  completion. 

Most  of  the  I/O  operations  in  the  S-3A  Operation  Program  occur  at  a periodic 
rate  and  are  requested  by  periodic  tasks  with  that  same  rate. 

Table  3-2  is  a list  of  each  subprogram  and  the  I/O  devices  it  communicates 
with.  For  each  I/O  device,  the  nominal  duty  cycle  (average  time  interval  be- 
tween data  transfers)  and  the  data  transfer  rate  are  listed. 

3.1.4  Executive  Functions 

The  purpose  of  the  executive  is  to  provide  an  initial  environment  for  the 
operational  program  and  to  provide  a focal  point  for  the  processing  of  all  inter- 
rupts. Since  most  of  executive  processing  requires  the  use  of  privileged  instruc- 
tions, the  majority  of  the  executive  operates  in  the  interrupt  state.  During 
mission  operations,  the  executive  is  primarily  concerned  with  the  management 
of  space  and  time  resources. 
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TABLE  3-2.  SUBPROGRAM  NOMINAL  I/O  RATES 


SUBPROGRAM 

I/O  DEVICE 

NOMINAL 

DUTY  CYCLE 

NOMINAL  RATES 
(words  per  second) 

EXEC 

ADP  No.  1 (Drum  1) 

Demand 

12000 

ADP  No.  2 (Drum  2) 

Demand 

12000 

KEYPAK 

INC  OS  No.  1 

50  msec  + Demand 

30 

ENCOS  No.  2 

50  msec  + Demand 

30 

INC  OS  No.  4 

Demand 

DISPAC 

MPD  No.  1 

25  msec 

20000 

MPD  No.  2 

25  msec 

20000 

MPD  No.  3 

25  msec 

13000 

MPD  No.  4 

25  msec 

6000 

NAV 

NDRC  No.  1 

200  msec 

60 

NDRC  No.  2 

200  msec 

60 

1 

CAINS 

50  msec 

120 

RAAWS 

200  msec 

5 

| 

CSAA 

200  msec 

10 

DGYS 

200  msec 

30 

AHRS 

50  msec 

30 

SRS 

1 sec 

40 

Steering 

(None) 

- 

- 

SLTA 

(None) 

- 

- 

COMM 

COMM 

Demand 

100 

Ballistics 

None 

- 

- 

ARMCON 

ARMCOS 

Demand 

24 

SESCON 

SESCOS 

Demand 

10 

ACC  ON 

ADP  No.  1 

Demand 

700 

ADP  No.  2 

Demand 

700 

ADP  No.  3 

100  msec  (max) 

100 

SRS 

1 sec 

4 

ATR 

100 

10 
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TABLE  3-2.  SUBPROGRAM  NOMINAL  I/O  RATES  (Continued) 


SUBPROGRAM 

I/O  DEVICE 

NOMINAL 

DUTY  CYCLE 

NOMINAL  RATES 
(words  per  second) 

PAC 

(None) 

- 

- 

ACTIVE 

(None) 

- 

- 

FLER 

FLIR 

50  msec 

75 

ALAD 

MAD 

42  msec 

24 

RADAR 

RADAR 

50  msec  (max) 

110 

ESM 

ESM 

250  msec 

100 

DEP 

DMTU 

1 sec/demand 

5000 

3. 1.4. 1 Space  Resources 

Available  areas  of  the  ADP  drums  and  main  memory  units  are  initially 
available  for  use  of  nonresident  segments  called  the  transient  area.  The  allo- 
cation, retrieval,  and  drum  handler  portions  of  the  executive  manage  the  allo- 
cation of  this  space  to  drum  segments  using  mapping  tables  and  queues  for 
requests. 

3. 1.4.  2 Time  Resources 

Time  resources  include  central  processor  (CP)  and  IOC  utilization  and  the 
allocation  of  I/O  channel  time  to  various  requestors.  S-3A  tasks  are  the  prime 
users  of  CP  time.  The  scheduler  and  dispatcher  portions  of  the  executive  have 
directories  and  queues  to  assist  in  controlling  CP  utilization.  The  centralized 
I/O  portion  of  the  executive  controls  the  usage  of  the  IOC  and  its  channels. 

3. 1.4.  3 Executive  Service  Requests 

A variety  of  executive  sendee  requests  (ESR's)  are  used  by  the  S-3A  tasks 
to  interface  with  the  executive  for  resource  utilization.  These  sendees  allow  a 
task  to  schedule  other  tasks,  to  read  or  write  drum  segments,  to  request  I/O 
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initiation,  to  save  CP  registers,  to  lock  or  unlock  data  tables,  to  allocate  tran- 
sient space  for  temporary  data  storage,  to  establish  or  remove  wait  conditions, 
and  to  increase  allowable  CP  execution  time. 

3. 1.4.  4 Operational  Program  Priority  Levels 

Each  function  within  the  S-3A  operational  program  is  assigned  to  one  of 
eight  levels  of  priority.  The  basic  driving  force  of  the  executive  is  the  sched- 
uling queue,  which  contains  the  list  of  tasks  currently  scheduled  according  to 
their  priority.  This  table  is  used  by  the  executive  to  select  the  highest  priority 
task  and  allows  the  task  to  use  CP  time.  When  tasks  are  encountered  that  are 
drum- resident,  the  executive  allocates  memory  space  to  the  segment  and  initi- 
ates retrieval  from  the  drum.  When  the  segment  retrieval  is  complete,  any 
scheduled  tasks  of  this  segment  are  eligible  for  dispatch. 

3. 1.4.  5 Executive  Recove rv  Component 

The  operational  program  is  capable  of  accommodating  a variety  of  equip- 
ment failures  without  loss  of  all  capability.  Failures  in  the  avionic  equipment 
are  addressed  in  the  EFPM  subprogram,  as  indicated  in  paragraph  3. 1.  2.  20. 
Failures  resulting  from  a loss  of  the  executive  resources  of  time  and  space  will 
be  handled  by  the  executive  recovery  component,  which  is  vested  with  the  re- 
sponsibility of  maintaining  some  meaningful  operational  capability  in  the  light 
of  such  resource  failures.  Depending  upon  the  nature  of  the  failure,  some 
capability  may  be  lost;  but,  in  general,  techniques  used  by  the  recovery  compo- 
nent will  either  reinitialize  the  system  or  reload  via  the  digital  magnetic  tape 
unit  (DMTU).  However,  for  all  failures,  the  operator  is  notified  via  system 
alerts;  and  the  error  is  extracted  on  the  DMTU. 

3.  2 APPLICATION  REQUIREMENTS 

The  following  paragraphs  discuss  the  results  of  applying  the  first  three 
stages  of  the  methodology  to  the  current  S-3A  avionic  information  processing 
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system.  As  indicated  previously,  these  stages  are  concerned  with  the  applica- 
tion requirements  and  functional  decomposition  aspects  of  the  methodology  and 
are  employed  to  partition  the  S-3A  information  processing  system  into  functional 
elements  establishing  baseline  requirements  for  performing  decentralized  archi- 
tectural studies.  In  addition,  control  strategy  requirements  for  implementing 
decentralized  architectures  are  also  addressed. 

3.  2. 1 Operational  Requirements 

Operational  requirements  are  determined  by  means  of  analyzing  the  func- 
tional aspects  of  the  subprograms/tasks  which  constitute  the  S-3A  operational 
program  (see  paragraph  3. 1.  2)  followed  by  a functional  partitioning  of  these 
software  elements  into  decompositional  units  and  elements. 

3.  2.1.1  Operational  Program  Functional  .Analysis 

The  S-3A  operational  program  can  essentially  be  considered  to  consist  of 
subprograms  executing  on  either  a periodic  or  demand  basis,  as  indicated  in 
Table  3-2.  Each  high-level  subprogram  module  is  made  up  of  a group  of  low- 
level  executable  modules  called  tasks.  A task,  which  can  either  continuously 
run  at  a periodic  rate  (periodic  task)  or  rim  as  a result  of  an  external  interrupt 
(demand  task)  usually  has  a defined  priority  and  iteration  rate.  However,  a 
subprogram  which  is  made  up  of  many  tasks  does  not  have  a definite  priority  or 
iteration  rate.  For  a high-level  analysis,  it  can  be  assrn  .ed  that  the  subpro- 
gram takes  on  the  priority  of  the  task  with  the  highest  priority  in  the  subsystem 
and  the  iteration  rate  of  the  task  with  the  highest  periodic  rate. 

3.  2. 1. 1. 1 Functional  Flow  Diagrams.  Each  subprogram  is  divided  into  many 
low-level  functions,  and  each  function  is  composed  of  one  or  more  tasks  (exec- 
utable code).  Information,  including  processing  time,  priority,  and  iteration 
rates,  was  compiled  for  these  low-level  functions  and  characterized  by  means 
of  functional  flow  diagrams.  Functional  flow  diagrams  consist  of  process  strings, 
represented  by  bubbles,  required  to  perform  the  function.  Due  to  the  extent  of 
these  flow  diagrams,  only  the  navigation  data  processing  function  is  provided  as 
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an  example  in  Figure  3-2.  The  reader  is  referred  to  Volume  1,  "S-3A  Func- 
tional Analysis,"  of  the  "S-3A  Information  Processing  Architecture  Study"  for 
a complete  description  (Reference  2).  As  shown  in  Figure  3-2,  the  flow  dia- 
grams are  arranged  such  that  processes  performed  in  the  CP  are  called  tasks, 
shown  on  the  left  side,  and  processes  performed  in  the  IOC  are  called  chains, 
shown  on  the  right  side.  Bubbles  connected  by  lines  indicate  that  the  process 
represented  by  the  first  bubble  has  scheduled  the  process  represented  by  the 
second  bubble.  Thus,  each  subsequent  bubble  is  referred  to  as  a successor  of 
the  immediately  preceding  bubble. 

3.  2. 1. 1.  2 Operator  Initiated  Functions.  Functions  that  are  initiated  frequently 
by  S-3A  operators  are  considered  as  having  a major  impact  on  the  system  and 
are  included  in  the  previously  discussed  functional  flow  diagrams.  Other 
operator-initiated  functions  that  only  cause  momentary  increases  in  system 
activity  are  considered  as  having  minor  impact  on  the  system.  The  minor  im- 
pact functions  are  summarized  in  tables,  an  example  of  which  is  shown  in 
Table  3-3  for  operator-initiated  functions  relative  to  displays.  The  reader  is 
again  referred  to  the  S-3A  functional  analvsis  report  (Volume  1 of  Reference  21 
for  a complete  description  of  operator-initiated  functions. 

3.  2. 1.2  Decompositional  Elements/Units  Partitioning 

.An  S-3A  requirement  decomposition  report  was  produced  under  the  S-3A  In- 
formation Processing  Architecture  Study  contract  and  contains  the  rationale  and 
approach  for  partitioning  S-3A  functions  into  decompositional  elements  iDE's) 
and  decompositional  units  (DU’s)  (Reference  3).  A DE  is  defined  as  "a  func- 
tional part  of  a system/application  without  regard  to  its  execution.  " A DU  is 
defined  as  "the  basic  component  of  the  methodology  consisting  of  one  or  more 
decompositional  elements,  implemented  in  hardware,  software,  or  firmware 
and  executed  as  required.  " As  a result  of  the  decompositional  analysis,  a total 
of  47  DU's  are  realized;  each  DU  comprises  various  DE's.  These  DU’s  are 
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Figure  3-2.  Functional  Flow  Diagram  Example 
(Navigation  Data  Processing) 
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TABLE  3-3.  OPERATOR-INITIATED  FUNCTIONS  EXAMPLE  (DISPLAY) 


FUNCTION 

DESCRIPTION 

AVERAGE  NO. 
ACTIVATIONS 

EXEC 

TIME 

Increase  Scale  (12)  PI 

This  function  increases  the 
tactical  display  scale  by  a 
factor  of  2. 

Decrease  Scale  (13)  PI 

This  function  decreases  the 
tactical  display  scale  by  a 
factor  of  2. 

Recenter  (11)  P5 

This  function  recenters  the 
tactical  display  about  a 
selected  point. 

Hook  Verify  (7)  PI 

This  function  allows  the 
operator  to  designate  sym- 
bols or  positions  on  the 
tactical  display  for  future 
operations. 

| 

Recenter  Pilot  (430> 

P3 

j 

. This  function  allows 
nonpilot  operators  to  re- 
center  the  pilot's  tacti- 
cal display. 

Recenter  on  Fly- 
To  Point  (403)  PI 

This  function  allows  the 
pilot  to  recenter  his 
tactical  display  on  the 
highest  priority  flv-to 
point. 

Recenter  On  .Air- 
craft i402)  PI 

This  function  allows  the 
pilot  to  recenter  his  tacti- 
cal display  on  the  own- 
aircraft  symbol. 

Auto  Down-  Scale 
(414)  PI 

This  function  allows  the 
pilot  to  keep  his  tacti- 
cal display  at  the  small- 
est scale  that  displays 
the  own-aircraft  symbol. 

Extend  Track  Vec- 
tor (552)  PI 

This  function  allows  the 
pilot  to  extend  the  track 
bearing  of  the  own-aircraft 
symbol  to  the  edge  of  his 
tactical  display. 

29  msec 


21  msec 


25  msec 


3 msec 


lo  msec 


15  msec 


15  msec 


1 msec 


3 msec 
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listed  in  Table  3-4  according  to  their  associated  sensors/subsystems,  and  a 
summary  of  the  general  types  of  functions  performed  by  each  DU  is  provided  in 

the  following  paragraphs 

j 

3.  2. 1.  2. 1 ESM  Intercept  Maintenance  (DU01) 

• Accesses,  processes,  and  updates  ESM  emitter  file 

• Places  tactical  display  in  ESM  display  mode 

• Displays  intercepts  on  the  MPD 

3.  2. 1.2.  2 ESM  F requencv  Control  (DU021 

• Performs  control  functions  associated  with  frequency  bands 
in  which  the  ESM  receiver  scans 

• Permits  operator  modification  of.  scan  bands  and  inhibits  lists 
3.2. 1.2.3  ESM  Classification  <DU03) 

• Displavs  possible  classifications  of  designated  signal 

• Permits  the  operator  to  specify  classification  of  specific 
intercept 

3.2.  1.2.  4 ESM  C mtact  Maintenance  DU04i 

• Enters  intercept  in  contact  file 
3.  2. 1.  2.  5 ADP  Mode  Control  iDUOol 

• Controls  various  modes  and  functions  of  the  ADP 

• Performs  initialization  of  ADP  subsystem  and  acoustic  functions 

• Provides  various  target  information  such  as  target  locations 
relative  to  sonobuoys 

3.2. 1.2.  6 ADP  Data  Management  iDU06j 

• Obtains  all  acoustic  data  inputs  from  the  ADP  and  stores  data 
in  a central  file  for  use  by  other  elements 

3.  2. 1.2.  7 ADP  Display  Control  (DUOTj 

• Establishes  the  MPD  and  auxiliary  readout  urit  (ARU)  acoustic 
display  modes  and  their  associated  annotation 

• Displays  alerts 
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• Displays  and  processes  responses  from  cues 

• Displays  tableau  and  processes  responses  from  tableau 
modification 

• Enters  and  updates  acoustic  contacts  and  fixes 

• Utilizes  track  ball  inputs 

3.  2. 1.  2.  3 SRX  Frequency  Control  (DUOS) 

• Provides  sonobuoy  receiver  initialization 

• Regulates  sonobuoy  receiver  input/output 

• Assigns  sonobuoy  receivers  to  ADP  processor  channels 

3.  2. 1.2.  9 ATR  Control  (DU09f 

• Provides  analog  tape  recorder  initialization 

• Provides  operator  interface  to  analog  tape  recorder 

• Provides  analog  tape  recorder  control 

3.2.1.2.10  ADP  Passive  Contact  Classification  fDUlCM 

• Places  MPD  in  classify  display  mode 

• Enables  operator  to  change  the  classify  mode  RF 

• Enables  operator  to  modify  stored  data  for  the  classify  RF 

• Provides  various  related  processing,  alert,  and  display  functions 

3.  2. 1.  2.  11  ADP  Passive  Contact  Maintenance  iDUlli 

• Provides  the  contact  data  matrix  which  permits  the  operator  to 
participate  in  contact  maintenance 

• Provides  functions  in  the  display  control  matilx  to  permit  the 
operator  to  monitor  contact  data 

3.2.1.2.12  ADP  Active  Ping  Control  (DU121 

• Controls  selection  of  command  active  and  directional  command 
active  sonobuoy  systems 

• Controls  sequence  of  pinging 
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TABLE  3-4.  DECOMPOSITIONAL  UNITS 


DECOMPOSITIONAL  UNIT  (DU) 

ASSOCIATED 

NOMENCLATURE 

NO. 

SENSOR/SUBSYSTEM 

ESM  Intercept  Maintenance 

01 

Electronic  Surveillance 

ESM  Frequency  Control 

02 

Measures  (ESM) 

ESM  Classification 

03 

ESM  Contact  Maintenance 

04 

ADP  Mode  Control 

05 

Acoustic  Data  Processing 

ADP  Data  Management 

06 

Subsystem  (ADP) 

ADP  Display  Control 

07 

i ADP  Passive  Contact  Classification 

10 

| ADP  Passive  Contact  Maintenance 

11 

1 ADP  Active  Ping  Control 

12 

| ADP  Active  Contact  Maintenance 

13 

l SRX  Frequency  Control 

08 

L 

Soncbuoy  Receiver  Subsystem  (SRX) 

ATR  Control 

09 

Analog  Tape  Recorder  (ATR) 

• 

MAD  Display  Control 

14 

Magnetic  Anomaly 

MAD  Data  Management 

15 

Detection  Subsystem  >MAD1 

MAD  Signal  Feature  Recognition 

16 

MAD  Contact  Maintenance 

1 

17 

1 

RADAR  Display  Control 

IS 

Radar  (RADAR) 

RADAR  Data  Management 

19 

RADAR  Contact  Maintenance 

21 

( Display  Operator  Control 

22 

S-3A  Tactical  Command  and 

Tactical  Display  Management 

23 

Control 

Display  Refresh  Management 

24 

Keyset  Control 

25 

Contact  Tracking 

43 

Tactical  Coordination 

44 

NAV  Position  Control 

26 

Navigation  Subsystem  (NAV) 

NAV  Position  Calculation 

27 

- NDRC  - AACS 

NAV  Data  Management 

28 

- INS  - DGVS 

; NAV  Track  History 

29 

- RAAWS  - AHRS 

Aircraft  Steering  Control 

37 
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TABLE  3-4.  DE COMPOSITIONAL  UNITS  (Continued) 


DE  COMPOSITIONAL  UNIT  (DU) 

ASSOCIATED 

NOMENCLATURE 

NO. 

SE  NSOR/SUBS  YSTE  M 

COMM  Receive 

30 

Communications  (COMM) 

COMM  Control 

31 

COMM  Data  Management 

32 

COMM  Transmit 

33 

Sonobuoy  Selection 

34 

Search  Stores  Control 

Sonobuoy  Release 

35 

Subsystem  (SESCON) 

Sonobuoy  Drop-Point  Calculation 

36 

Ballistics 

20 

Armament  Control 

Weapon  Release 

33 

Subsystem  (ARMCON) 

Weapon  Drop  Point  Calculation 

39 

Weapon  Selection 

40 

1 

SRS  Control 

41 

Sonobuoy  Reference 

Sonobuoy  Position  Calculation 

42 

i 

Subsystem  (SRS) 

FLLR  Contact  Maintenance 

45 

Forward-Looking  Infrared 

FLIR  Display  Control 

46 

Subsvstem  (FLIR) 

FLIR  Stabilization 

47 

1 

3.2.1.2.13  ADP  Active  Contact  Maintenance  i,DU13) 

• Provides  for  entering  and  updating  active  acoustic  contacts 
3.  2. 1.  2. 14  MAD  Display  Control  iDU14) 

• Permits  the  operator  to  display  real-time  MAD  signal  data 

• Establishes  the  controlling  operator  and  availability  of  MAD 
functions 


3.2.1.2.15  MAD  Data  Management  (DU15) 

• Obtains  input  data  from  MAD  subsystem  and  stores  it  in  a file 
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3.  2. 1.  2. 16  ^A.D  Signal  Feature  Recognition  (DU16) 

• Initiates  feature  recognition  processing 

• Performs  MAD  data  analysis 

3.2.1.2.17  MAD  Contact  Maintenance  (DU17) 

• Permits  the  operator  to  enter  a MAD  fix  into  the  system  based  on  the 
position  of  the  horizontal  cursor  on  MAD  display 

• Permits  the  operator  to  accept  an  automatically  detected  MAD  signal 
as  a MAD  fix  and  enter  it  into  the  system 

3.  2.1.  2.  IS  Radar  Display  Control  (PUIS) 

• Permits  the  operator  to  control  radar  set  configuration  by  selection 
of  appropriate  control  function 

• Provides  radar  display  and  control 

• Provides  scan  converter  control 

• Provides  antenna  control 

3.2.1.2.19  Radar  Data  .Management  (DL'19l 

• Provides  all  data  communication  to  and  from  the  radar  subsvstem 
3.  2. 1.  2.  20  Ballistics  <Dl'201 

• Determines  speed  and  motion  of  buoys  and  weapons  when  in  flight 

3.2.1.2.21  Radar  Contact  Maintenance  iDL'211 

• Permits  the  operator  to  enter  radar  fixes  into  the  system 

3.2.1.2.22  Display  Operator  Control  (DU22) 

• Provides  operator  aids,  functions,  and  requests  to  enable  tableaus, 
cues,  and  alerts  to  be  displayed 

3.2.1.2.23  Tactical  Display  Management  iDl'23l 

• Manages  the  tactical  plot  area  of  each  display 

• Provides  manual  entry  functions  to  assist  the  operator  in  processing 
inputs 

• Provides  the  operator  with  various  control  functions,  including  tableau 
and  symbology  control 
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3.  2. 1.  2.  24  Display  Refresh  Management  (DU24' 


r 


i 

,, 

• Formats  the  data  buffer  and  transfers  data  to  all  tactical  displays 
maintaining  an  updated  presentation 

3.2.1.2.25  Keyset  Control  (DU25) 

• Interprets  key  depressions  of  operator's  Integrated  Control  Subsystem 
(INCOS)  trays 

• Sends  lighting  commands  to  INC  OS  trays  and  table 

• Schedules  associated  units 

• Processes  trackball  inputs  from  DsCOS  trays 

3.  2. 1.  2.  26  XAV  Position  Control  (DU26) 

• Initializes  navigation  system 

• Activates  dead-reckoning  processing 

• Activates  and  modifies  Zulu  timekeeping 

• Enters  and  displays  navigation  symbols  and  grid  coordinates 

• Initiates  and  terminates  the  tactical  mode  of  navigation 

• Allows  operator  correction  of  aircraft  tactical  position 

• Modification  and  computation  of  bias  velocity 

• Allows  operator  correction  of  tactical  positions  of  buoys,  contacts, 
and  fixes 

• Sets  position  of  buoy  and  contacts  to  last  aircraft  position 

• Corrects  aircraft  geographic  position 

• Operator  inputs  of  magnetic  variation  or  Carrier  Aircraft  Aligned 
Inertial  Navigation  System  (CAINS)  data 

3.  2. 1.  2.  27  XAV  Position  Calculation  (DU27) 

• Computes  aircraft  position  from  XAV  sensor  data 

• Stores  latitude/longitude  for  output  to  the  inertial  navigation  subsystem 
(INS)  and  the  altitude  and  heading  reference  subsystem  (AHRS) 

3.  2. 1.  2.  28  XAV  Data  Management  1DU23) 

• Receives,  converts,  maintains,  and  stores  signal  data  from  the 
XAV  subsystem 
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3.2.1.2.29  NAV  Track  History  (Dl'291 

• Allows  the  operator  to  display  the  ASVV  support  aircraft  carrier  (CVS) 
computed  position 

• Maintains  CVS  position,  course,  and  velocity 

• Maintains  the  track  history  of  aircraft 

3.2.1.2.30  COMM  Receive  (DU301 

• Receives,  converts,  and  maintains  data  from  COMM  subsystem 

3.2.1.2.31  COMM  Control  (DU31) 

• Initializes  COMPAC  module 

• Transmits  all  data  on  link  in  one  transmission  during  data  silence 

• Retransmits  the  data  terminal  set  (DTS)  and  deactivates  Net 

• Configures  hardware  before  starting  Net 

• Configures  Net  in  receive-only  silence  mode 

• Activates  Net  and  performs  synchronize  and  control  functions 

• Monitors  status  of  COMM  subsystem  for  faults  uid  configuration 
changes 

3.2.1.2.32  C OMM  Data  Management  tDl'321 

• Allows  the  operator  to  assign  data  to  net,  assign  special  points  of 
interest,  recenter  display,  specify  engagement  status,  assign  contact 
status  to  buoy,  and  assign  the  identification  friend  or  foe  (IFF)  selec- 
tive identification  feature  (SEF)  code  to  track  on  net 

• Transfers  COMM  data  base  to  another  aircraft 

• Transmits  emergency  alerts  of  data  on  Net 

• Corrects  and  updates  aircraft  position 

• Inhibits  remote  data  from  display 

• Displays  link  track  numbers 

• Unlinks  data  from  net,  destroys  COMM  data,  and  purges  old  data 


3-25 


I 

MADC- 79 161-40 

• Formats  on- station  message 

• Acknowledges  order  received  and  answers  it 

• Puts  emergency  message  on  Met 

3.2.1.2.33  COMM  Transit  (DU33) 

• Maintains,  converts,  and  transmits  communication  data  to  the 
COMM  transmitters 

3.  2. 1.  2.  34  Sonobuoy  Selection  (DU 34) 

• Resets  and  initializes  SESCON  module 

• Allows  the  operator  to  modify  parameters  in  the  search  stores 
inventory 

• Allows  the  operator  to  select  one  of  the  following  buoys  for  release: 
low-frequency  acquisition  and  ranging  (LOFAR),  directional  LOFAR 
(DIFAR),  command  activated  sonobuoy  system  (CASS),  directional 
CASS  (DICASS),  bathythermograph  iBT),  range  only  <RO),  sound  under- 
water signal  (SUS)  or  Smoke 

• Allows  the  operator  to  enter  a pattern  of  fly-to  points  into  the 
system  and  to  select  a sonobuoy  for  release  at  each  point 

3.2.1.2.35  Sonobuoy  Release  *DU35! 

• Performs  release  of  sonobuoy  from  aircraft  and  insertion  of  buoy 
into  system,  executing  upon  demand 

• Updates  search  stores  inventor,' 

3.2.1.2.36  Sonobuoy  Drop-Point  Calculation  (DU36) 

• Calculates  the  fly-to  point  of  a sonobuoy 

3.2.1.2.37  Aircraft  Steering  Control  (DU37) 

• .Allows  the  operator  to  assign  a constant  radius  aircraft  orbit  about  a 
chosen  point 

• Initiates  circular  orbit  about  an  active  range  buoy  with  an  orbit  radius 
equal  to  and  varying  with  target  range 

• Computes  and  displays  the  intercept  point  between  target  and  aircraft 

• Allows  the  operator  to  enter  and  display  fly-to  points 


3-26 


NADC- 79161-40 

• Computes  synthetic  fly-to  points  for  aircraft  control  in  special 
steering  patterns 

• Determines  desired  ground  track  in  directing  aircraft  to  fly-to  point 
and  furnishes  data  to  the  navigation  data  repeater  and  converter  (NDRC) 

3.2.1.2.38  Weapon  Release  (DU38) 

• Releases  selected  weapon(s)  on  demand 

3.2.1.2.39  Weapon  Drop  Point  Calculation  (DU39) 

• Calculates  the  fly-to  point  of  a weapon 

3.2.1.2.40  Weapon  Selection  (DU40) 

• Initializes  the  ARMCOS  function 

• Selects  bomb,  cluster  bomb,  mine,  practice  bomb,  special  weapon, 
or  torpedo  for  release 

3.2.1.2.41  Sonobuov  Reference  Subsystem  (SRS)  Control  iDl'41) 

• Selects,  deselects  sonobuoys  for  SRS  processing 

• Initiates  SRS  buoy  positioning  processing 

• Monitors  SRS  for  hardware  failures 

• Computes  calibration  factors  for  SRS  processing 

3.2.1.2.42  Sonobuov  Position  Calculation  iDU42) 

• Computes  sonobuoy  positions 

• Computes  sin/cos  of  SRS  on-top  position  indicator  (OTPI)  bearing 

• Computes  calibration  factors  for  angle-measuring  equipment  (AME) 
and  direction- measuring  equipment  <DME)  data 

• Does  preliminary'  processing  and  scheduling  and  requests  I/O  for 
SRS  calibration  and  normal  processing  routines 

3.  2. 1.  2.  43  Contact  Tracking  (DU43) 

• Updates  intercept,  predicts  position  and  active  sonobuoy-to-MAD 
attack  tactics  (ASMAT)  contacts 

• Updates  probability  contours 

• Updates  tracks 
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3.2.1.2.44  Tactical  Coordination  (DU44) 

• Enters  visually  identified,  operator  specified,  and  computed  fixes 
(the  latter  at  intersections  of  bearing  lines  or  range  circles  associated 
with  two  contacts) 

• Displays  probability  ellipse  about  a fix,  track,  or  in-flight  training 
program  (IFTP) 

• Displays  circle  about  target  position  containing  possible  locations 
of  target  when  aircraft  arrives  at  position 

• Enters  local  data  into  system 

• Constructs  target  track  based  on  fixes 

• Displays  fix  positions  for  a generated  track 

• Allows  operator  to  modify  track  number  and  category  identification 
of  fix  or  track 

• Estimates  current  position  of  target  and  computes  and  displays 
predicted  position  for  a given  target  at  specified  time 

• Calculates  parameters  for  ACTIVE  RANGE  tableau 

• Computes  and  displays  a suggested  pattern  for  CASS  and  RO  buoy 
deployment 

• Allows  operator  to  acknowledge  entry  of  new  contacts 

3.2.1.2.45  FLIR  Contact  Management  iDU45) 

• Enters  and  maintains  FLIR  fix 

3.2.1.2.46  FLIR  Display  Control  iDU46) 

• Initializes/disables  computer  control  of  FLIR  hardware 

• Activates  FLIR  cooling  fans  and  sensors 

• Extends/retracts  FLIR  outside/inside  aircraft 

• Displays  FLIR  mode  on  MPD 

• Adjusts  brightness/contrast  and  modifies  image  resolution 

• Reverses  FLIR  polarity 

3.2.1.2.47  FLIR  Stabilization  (DU47) 

• Pans  a given  sector  in  manual  track  mode 

• Initiates  the  FLIR  auto  track  mode 

• Performs  FLER  output  and  positioning  commands 
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Decompositional  elements  have  now  been  defined  for  the  BASIC  application. 
The  next  step  in  the  methodology  is  the  synthesis  of  a control  structure  which 
relates  the  DU!s  to  one  another.  The  objective  of  this  paragraph  is  to  define 
such  a control  structure. 

The  first  step  is  to  define  a comprehensive  set  of  functions  necessary  for 
the  control  of  data  processing  software  and  hardware  in  an  avionic  system  with 
operational  requirements  similar  to  those  of  the  S-3A.  These  functions  will 
provide  a baseline  set  of  control  requirements  suitable  for  incorporation  into 
the  BASIC  concept. 

3.  2.2.  2 Characteristics  of  Avionic  Computer  Processes 

Before  developing  a set  of  control  functions,  the  nature  of  the  controlled 
processes  must  be  well  understood.  One  primarv  characteristic  of  avionic 
processes  is  that  they  ire  predefined  and  do  not  change  during  a particular  mis- 
sion. Only  the  sequence  in  which  the  processes  execute  is  not  known  beforehand 
Thus,  much  of  the  environment  and  interfaces  required  by  a particular  process 
can  be  defined  at  system -generation  time;  this  relieves  the  run-time  control 
mechanism  of  these  burdens.  The  other  primary  characteristic  of  avionic  proc- 
esses is  that  they  are  all  interrelated  to  some  degree  and  that  they  all  contribute 
to  the  execution  of  a single,  overall  function,  called  the  mission.  For  this  reason, 
the  efficiency  of  the  control  structure  must  be  measured  in  terms  of  contribution 
to  mission  success,  which  is  a complex  and  ill-defined  measure,  rather  than  in 
terms  of  percentage  of  overall  time  required  for  control,  which  is  a standard 
measure  for  a batch  processing  environment. 

In  general,  avionic  processes  execute  in  one  of  three  modes:  synchronous, 
demand,  and  background.  In  the  synchronous  mode,  processes  are  dispatched 
periodically  and  are  expected  to  be  complete  before  the  next  dispatch.  Most  of 
the  processing  time  in  avionic  systems  is  used  by  synchronous  processes.  In  the 
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demand  mode,  processes  are  dispatched  as  a result  of  an  interrupt,  usually 
generated  by  a keyset  depression.  Most  of  the  tasks  executed  by  an  avionic 
system  are  demand  mode  tasks.  They  do  not,  however,  constitute  a heavy  load 
on  the  processing  resources.  Background  tasks  are  low-priority  tasks  executed 
whenever  the  processor  is  not  otherwise  occupied.  Avionic  processes  usually 
require  more  program  storage  than  data  storage,  and  the  data  is  usually  updated 
periodically.  The  ratio  of  program  storage  required  to  data  storage  required 
runs  from  35  percent  for  F-15  fighter  aircraft  to  50  percent  for  E-2C  surveil- 
lance aircraft. 

3.  2.  2.  2.  1 Synchronous  Processes.  Synchronous  processes  are  scheduled  and 
dispatched  periodically  by  the  control  mechanism.  In  general,  they  operate  on 
sensor  data  which  is  always  being  updated  at  a particular  rate  determined  by  the 
sensor.  It  is  therefore  necessary  that  the  periodic  processes  utilize  the  data  be- 
fore it  gets  overwritten  by  new  data. 

In  the  avionic  environment,  time  is  measured  in  terms  of  cycles.  Each 
cycle  is  a small  increment  >50  msec  for  the  S-3Ai,  and  all  time  is  measured  in 
integer  numbers  of  evcles.  Thus,  a periodic  process  is  dispatched  every  X 
cycles  and  must  be  complete  within  a certain  number  of  cycles.  This  method 
allows  the  control  mechanism  two  options  if  a process  cannot  be  dispatched  or 
completed  on  time;  either  the  start  of  a new  cycle  can  be  delayed,  or  the  process 
can  be  aborted. 

In  the  S-3A,  the  synchronous  tasks  account  for  almost  all  the  processor 
loading,  while  the  actual  number  of  synchronous  tasks  is  only  10  percent  of  the 
total  number  of  tasks  executed  by  the  system. 

3.  2.  2.  2.  2 Demand  Tasks.  Demand  tasks  are  most  often  executed  in  response 
to  an  operator-generated  interrupt  and  generally  result  in  a change  to  the  display 
issociated  with  that  operator.  Demand  tasks  cannot  be  prescheduled,  as 
can  synchronous  tasks.  This  presents  a more  difficult  problem  to  the  control 
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mechanism,  since  it  must  recognize  the  interrupt,  decide  which  process  is  to  be 
executed,  interrupt  and  save  the  state  of  the  currently  executing  process,  dispatch 
the  demand  task,  and  restore  the  previous  process  when  the  demand  task  is  com- 
plete. 

On  the  average,  demand  tasks  require  about  2 msec  of  processing  time  out 
of  every  second.  However,  out  of  the  331  tasks  identified  for  the  S-3A  processing 
system,  295  (39  percent)  are  demand  tasks,  while  only  36  are  synchronous. 

The  performance  measure  of  the  control  structure  with  respect  to  demand 
tasks  is  the  time  which  is  required  to  start  execution  of  the  process  after  the 
interrupt  is  received.  This  time  can  be  quite  critical,  especially  if  the  demand 
interrupt  is  caused,  not  by  an  operator  action,  but  by  the  identification  of  certain 
parameters  in  sensor  data.  These  data  may  require  additional  special  processing 
before  they  are  overwritten;  thus,  speedy  dispatch  of  the  appropriate  process  is 
necessary. 

3.  2.  2.  2.  3 Background  Tasks.  Background  tasks  are  executed  when  no  demand 
tasks  have  been  requested  and  no  synchronous  task  is  readv  for  execution.  Test 
programs,  bus  polling  processes,  and  certain  functions  of  the  executive  are 
normally  background  processes. 

3.  2.  2.  2.  4 Interrupt-Activated  Processes.  Occasionally,  an  avionic  process 
operates  in  a combination  of  demand  and  synchronous  modes.  This  occurs  when 
an  interrupt  causes  a synchronous  process  to  become  active.  After  activation, 
the  process  behaves  exactly  as  a synchronous  task  until  another  interrupt  de- 
activates it,  after  which  it  is  no  longer  scheduled  on  a periodic  basis.  These 
interrupt-activated  processes  are  usually  associated  with  the  operator’s  desire 
to  see  a particular  display  format  for  a time  and  then  return  to  his  normal  dis- 
play format.  Thus,  the  process  is  synchronously  executing  only  as  long  as  the 
operator  desires  to  display  the  results.  Otherwise,  the  process  is  not  executing. 
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3.  2.2.  2.  5 Functions.  Avionic  processes,  in  a very  general  sense,  are  con- 
cerned with  the  display  of  data  gathered  by  the  sensors.  A typical  sequence  of 
processes  for  a mission  sensor  would  input  sensor  date;  filter  it  to  remove 
noise;  compensate  for  the  position,  heading,  motion,  and  physical  geometry  of 
the  aircraft;  decide  if  a detection  has  occurred;  and,  if  it  has,  format  the  data 
for  display  on  a cathode  ray  tube  (CRT).  These  processes  usually  perform 
numerous  trigonometric  and  averaging  calculations.  Data  accuracy  and  resolu- 
tion is  usually  in  the  3 to  16  bit  range.  Considerable  man-machine  cooperation 
is  necessary  to  detect  and  classify  objects  perceived  by  the  various  aircraft 
sensors,  thus  leading  to  the  large  number  of  demand  tasks  required.  Naviga- 
tion and  communication  processes  also  filter  data  received  from  sensors,  com- 
pensate for  aircraft  parameters,  and  display  the  results.  These  processes  do 
not,  however,  require  detection  and  classification  functions. 

3.  2.  2.  3 Avionic  Processing  Environment 

There  are  several  important  characteristics  of  the  processing  environment 
that  must  be  considered  in  the  definition  of  a control  structui'e.  A process  exe- 
cutes in  an  environment  which  can  partly  be  controlled  by  the  system  designer 
through  definition  of  the  system  architecture  and  is  partly  beyond  the  designers' 
control  because  of  weight,  cost,  and  state-of-the-art  constraints.  For  example, 
the  designer  would  normally  not  choose  to  increase  radar  reliability  by  imple- 
menting dual  surveillance  radar  systems,  such  as  that  on  the  E-2C,  since  the 
weight  and  cost  penalty  would  be  too  great.  Similarly,  no  amount  of  architec- 
tural manipulation  will  enable  an  avionic  system  to  detect  and  classify  targets 
beyond  the  range  of  any  of  its  sensors.  The  primary  impact  of  these  weight, 
cost,  and  state-of-the-art  constraints  on  the  control  mechanism  is  in  the  areas 
of  signal  processing  and  fault  tolerance. 

Although  there  is  no  theoretical  difference  between  signal  and  data  proc- 
essing, there  is  an  undeniable  practical  and  architectural  difference.  Signal 
processing  must  be  performed  at  a speed  much  greater  than  can  be  attained  by 
a general-purpose  data  processor.  As  a result,  signal  processing  devices  are 

3-32 


i 


NADC-79161-40 

generally  high-technology  devices  whose  internal  architecture  is  matched  with 
the  sensoris)  it  services.  Signal  processors  are  larger  and  more  expensive 
than  data  processors  and  require  more  power  and  a greater  attention  to  physical 
geometry  because  of  their  higher  speeds  for  internal  data  transfer.  They  are 
architecturally  geared  for  limited  applications.  As  such,  the  processing  system 
designer  has  very  little  freedom  in  the  number  and  type  of  signal  processors  he 
may  use.  For  this  reason,  signal  processors  have  been  removed  from  consider- 
ation as  part  of  the  data  processing  system  and  will  henceforth  be  considered  as 
part  of  the  particular  sensor  subsystem  in  which  they  are  used. 

The  ability  of  a system  to  recover  from  a fault  is  also  constrained  by  weight 
and  cost  factors.  As  stated  before,  it  is  unrealistic  to  duplicate  large  and  ex- 
pensive sensors  to  provide  better  fault  tolerance;  therefore,  it  is  unrealistic  to 
expect  to  maintain  full  performance  in  the  face  of  anv  fault  that  may  occur. 
Likewise,  it  is  inefficient  to  provide  a computer  with  fault  tolerance  capabilitv 
such  that  the  mean  time  between  failures  (MTBFi  of  the  computer  exceeds  the 
reliability  of  any  of  the  sensors  it  mav  sendee  by  more  than  a factor  of  five  or 
six. 

In  cases  like  this,  it  is  required  that  the  system  be  able  to  lose  the  capa- 
bilitv provided  bv  the  sensor  without  a complete  system  crash.  That  is,  the 
system  must  be  capable  of  providing  the  maximum  performance  possible  with- 
out the  data  normally  provided  by  the  failed  sensor.  Such  graceful  degradation 
can  be  provided  for  in  the  design  of  the  architecture. 

Many  aspects  of  the  processing  environment,  however,  are  under  the  con- 
trol of  the  processing  system  designer.  Complete  recovery  from  a processor 
fault  can  be  attained  through  the  proper  use  of  redundant  processing  hardware 
and  interface  paths.  Flexibility  and  growth  can  be  built  into  the  system  so  that 
increased  or  modified  requirements  can  be  met  at  minimum  costs,  or  new 
technology  can  be  easily  incorporated  to  improve  performance. 
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With  this  understanding  of  the  avionic  processes  and  their  env.ronment,  a 
set  of  control  functions  for  the  architecture  may  now  be  defined.  The  following 
paragraphs  describe  the  control  functions  recommended  for  the  BASIC  proc- 
essing system. 

3.  2.  2.  -I  Functional  Requirements  for  Control  of  a Multiple  Computer  System 

The  functions  necessary  for  control  of  a processing  system  can  conveniently 
be  broken  into  two  categories;  local  control,  which  deals  with  the  internal  actions 
of  each  computer;  and  global  control,  which  coordinates  and  manages  the  inter- 
actions among  the  various  computers.  This  division  and  the  functions  required 
for  each  category  are  shown  graphically  in  Figure  3-3  and  are  described  in 
detail  below. 

3.  2.  2.  4. 1 Local  Control  Functions 

a-  Initialization.  The  computer  should  be  capable  of  putting  itself  into  a 
state  in  which  it  can  perform  self-check  and  inform  an  external  source 
of  the  results  of  the  self-check.  If  the  self-check  indicates  a working 
con  din  on,  then  the  computer  should  be  capable  of  performing  any  of  the 
following  subfuncrions 

ill  Reload  — This  function  performs  a master  clear  of  all  necessary 
computer  status  and  register  contents,  and  executes  a resident 
bootstrap  load  program. 

(2)  Cold  Start  — After  self-check,  the  computer  executes  a master 
clear  and  initializes  any  necessary  control  information  from  data 
loaded  via  the  bootstrap  loader.  A prespecified  process  then 
begins  execution. 

(3)  Autostart  — This  function  reinitializes  the  computer  after  an  inter- 
rupt has  occurred  because  of  a hardware  failure  (for  example,  low- 
power).  Data  for  reinitialization  shall  have  been  stored  in  non- 
volatile memory  by  the  interrupt  service  routine. 

b.  Timekeeping 

A timekeeping  mechanism  is  necessary  for  this  internal  use  of  applica- 
tion processes  and  for  the  scheduling  of  synchronous  programs.  In 
addition,  system  time  in  terms  of  cycles  must  be  kept  to  aid  in  coordina- 
tion of  interdependent  processes  executed  on  different  computers. 
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c.  Event  Handling,  Each  computer  must  have  a mechanism  for  servicing 
events  generated  by  hardware  conditions,  by  application  processes, 
and  by  the  global  control  mechanism.  In  handling  an  event,  the  pre- 
sently executing  process  in  interrupted;  and  a predefined  application 
process,  particular  to  that  event,  is  executed.  For  most  events,  the 
state  of  the  machine  is  saved  before  the  event  processor  is  entered, 
and  the  interrupted  process  is  continued  after  the  event  is  serviced. 
Some  events,  however,  may  require  complete  reinitialization  of  the 
computer. 

d.  Scheduling.  This  function  determines  at  what  time  an  application 
process  is  ready  to  be  executed  in  the  local  computer.  This  may  or 
may  not  involve  interacting  with  the  global  control  mechanism. 

e.  Dispatching.  This  function  creates  the  proper  local  environment  for 
an  application  process  and  transfers  control  to  the  application  process, 
which  then  executes  on  the  computer.  This  function  will,  in  some 
cases,  require  coordination  with  the  global  control  mechanism. 

f-  f,  O Management.  This  function  provides  a standard,  structured  inter- 
face between  application  processes  and  the  peripherals  or  other  com- 
puters with  which  these  processes  must  communicate.  This  function 
must  be  closely  coordinated  with  the  global  control  mechanism. 

Synchronization.  This  function  determines  if  all  the  resources  and  data 
necess ary  for  the  execution  of  a process  are  available  for  use  by  that 
process. 

h-  Error  Management.  This  function  detects  errors  in  the  local  computer, 
corrects  the  error  if  possible,  determines  the  status  of  the  computer, 
and  informs  the  global  control  mechanism  of  the  error  and  the  computer 
status. 

i-  Data  Protection.  This  function  assures  that  memory  contents  are 
accessed,  modified,  or  executed  only  by  those  processes  which  have 
been  given  proper  authority  to  do  so.  This  is  one  mechanism  for 
protecting  the  system  data  from  hardware  faults  (especially  non- 
recurring faults)  and  software  errors. 

• 2.  4.  2 Global  Control  Functions 

a*  Initialization  Control.  The  initialization  control  function  is  composed 
of  the  following  subfunctions  (See  Figure  3-4); 

<11  Initial  Checkout  — The  avionics'  initialization  controller  (any  of  the 
processors)  is  loaded  from  a load  device  containing  unit  test  soft- 
ware designed  to  verify  the  integrity  of  the  system.  Self-test  is 
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Figure  3-4.  Initialization  Control  Function  Hierarchy 

performed  internally  by  tne  controller  and  includes  the  CPC  and 
external  memories.  Loop  tests  are  conducted  between  die  controller 
and  the  individual  avionic  subsystems  in  order  to  verify  the  commu- 
nication links.  Configuration  data,  which  establish  the  various 
operating  modes  of  the  subsystem  elements,  are  loaded  from  the 
initialization  controller  into  each  of  the  avionic  subsystems.  The 
initial  checkout  process  includes  a verification  that  a fault  is  sensed 
and  reported  to  an  appropriate  display.  The  system  controller  directs 
each  subsystem  processor  to  execute  its  built-in  test  function  and 
report  the  results  back  for  appropriate  display.  The  system  con- 
troller tabulates  the  results  received  from  die  initial  checkout  proc- 
ess and  reports  the  checkout  as  being  either  Go  or  N'o-Go.  A N'o-Go 
report  will  effect  a system  shutdown. 

i21  System  Test  — The  system  test  subfunction  requires  a hardware  diag- 
nostic program  to  be  nan  for  the  total  system,  including  subsystem 
interfaces  and  each  subsystem.  The  system  test  verifies  the  proper 
operation  of  the  equipment  in  the  system  ind  reports  as  to  the  proper 
operation  or  malfunctioning  of  a specific  subsystem.  The  system 
test  isolates  the  problem  within  the  malfunctioning  subsystem  to  a 
specific  subunit  or  group  of  pages  that  can  be  replaced  in  order  to 
rectify  the  problem. 
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(3)  Program  Load  — Following  a successful  initial  checkout  and  system 
test,  the  operational  software  is  loaded  into  each  of  the  subsystem 
processors  with  their  respective  operational  software.  Each  sub- 
system reports  the  successful  loading  of  its  operational  software 

to  the  system  controller. 

(4)  Data  Load  — The  system  is  provided  with  data  on  magnetic  tape, 
which  permits  optional  configuration  for  prosecution  of  designated 
targets.  The  data  include  target  classification  information  (that 

is,  frequency  components,  radar  characteristics),  desired  operating 
modes  for  each  of  the  subsystem  processors,  position  of  friendly 
forces,  and  so  forth.  These  data  will  be  made  available  for  each 
mission. 

(5)  Avionics'  Initialization  — The  avionic  subsystem  must  be  initial- 
ized to  a specified  state  before  the  operational  software  is  exe- 
cuted. The  system  controller  will  issue  the  required  commands 

to  each  of  the  subsystems  to  place  these  subsystems  in  the  required 
state.  Failure  to  perform  this  initialization  function  will  cause  the 
software  operating  system  to  report  a software  system  error. 

b.  Pa  caver"  iTigure  3-3)  The  recover.-  function  provides  for  the  following 

contingency:  when  a subsystem  fails  and  this  failure  is  recognized  and 
isolated  by  the  in-flight  performance  monitoring  software,  the  svstem 
can  be  reconfigured  either  automaticallv  or  manually  into  a degraded 
mode;  and  the  mission  can  proceed.  The  system  will  select  the  desired 
configuration  and  proceed  with  the  initialization  function.  At  the  comple- 
tion of  the  initialization  process,  the  system  will  enter  the  information 
contained  in  the  checkpoint  status  data  base.  This  data  base  contains 
subsvstem  configuration  status  information,  which  includes  the  opera- 
ting mode  for  each  processor  and  stores  inventor-,  and  problem  data, 
which  include  tactical  display  inputs,  sensor  classification  coeffi- 
cients, and  navigation  computations.  At  the  completion  of  the  recovery 
process,  the  system  will  display  a message  that  the  recover-  has  been 
successful  along  with  the  resultant  degraded  configuration. 

c.  Svstem  Configuration  /Figure  3-6).  The  system  is  required  to  maintain 
status  with  each  of  the  subsystem  processors  to  verify  that  the  commu- 
nication link  is  operating  properly  and  that  the  subsystem  is  properly 
configured.  The  system  will  format  and  receive  messages,  as  sched- 
uled by  the  executive,  to  verify  the  configuration  status  of  each  of  the 
subsystems  and  peripherals.  The  system  also  has  the  capability  to 
reconfigure  any  of  the  subsystems  to  a new  configuration. 
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Figure  3-5.  Recovery  Control  Function  Hierarchy 


Figure  3-*5.  System  Configuration/Status  Control  Function  Hierarchy 
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Recovery  data  in  the  form  of  configuration  status  and  problem  data 
are  periodically  collected  by  the  system  for  each  of  the  subsys- 
tems and  stored  on  magnetic  tape  (or  other  medium).  These  re- 
covery data  are  used  by  the  system  to  restore  mission  operation 
after  a system/subsystem  failure. 

In  addition  to  monitoring  the  configuration  status  of  each  subsys- 
tem, the  system  also  monitors  the  vehicle  status.  Such  parameters 
as  fuel  status,  attitude,  and  temperature  are  monitored  and  displayed. 

In  the  case  of  a failure  of  the  system  controller,  another  subsystem 
CPU  will  assume  the  function  of  system  controller.  The  initializa- 
tion and  recover}'  procedures  will  then  take  place  to  load  and  configure 
the  system  in  the  new  degraded  mode. 

Bus  Control  (Figure  3-7).  The  bus  control  function  provides  for  the 
passing  of  messages  among  processes  executing  in  different  computers. 
In  this  capacity,  this  function  is  concerned  with  bus  access  control, 
bus  error  management,  and  bus  reconfiguration  in  case  of  failure. 

The  bus  control  function  also  provides  each  computer  access  to  nec- 
essary system- wide  global  variables.  Specifically,  the  following  sub- 
functions  make  up  the  bus  control  function: 

11  Message  Processing  — Messages  passed  between  avionic  units 
may  be  classified  into  three  categories:  svnehronous  messages, 
asynchronous  messages,  and  critically  timed  messages.  It  is 
the  responsibility  of  the  bus  control  function  to  assure  that  these 
messages  are  transmitted  and  received  correctly  within  the  time 
limitations  of  their  particular  category. 

Synchronous  messages  must  be  transmitted  on  a periodic  basis 
(that  is,  an  integer  number  of  cycles  apart).  Asynchronous  mes- 
sages are  initiated  upon  request  of  some  process,  such  as  a re- 
quest for  data  by  a demand  task,  or  a status  update  from  a text 
program.  Critically  timed  messages  are  those  which  must  occur 
at  a finer  time  resolution  than  a single  cycle.  The  bus  control 
must  provide  a timing  mechanism  for  these  messages  as  well  as 
a priority  access  to  the  bus  so  that  their  transmission  is  assured 
in  a timely  manner. 
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Figure  3-i.  3us  Control  Function  Hierarchy 

(2)  Error  P roc e s s i na  — This  subfunction  is  required  to  detect,  isolate, 
and  recover  from  faults  in  the  message  or  message  path.  The  bus 
control  must  be  able  to  identify*  faulty  messages  and  either  correct 
them  or  take  some  action  to  assure  that  they  are  not  taken  as  cor- 
rect by*  the  rest  of  the  system.  Recovery  mav  be  by  use  of  error 
correction  mechanisms,  retry,  or  cancellation  of  the  message  and 
reconfiguration  using  available  excess  hardware  and  software  re- 
sources. The  bus  control  function  must  be  capable  of  detecting, 
isolating,  and  recovering  from  faults  within  its  own  mechanism. 

131  System  Variable  Access  — The  bus  control  function  must  provide 
each  unit  on  the  bus  with  the  capability  to  access  any  global  vari- 
ables and  semaphores.  This  is  considered  a different  category* 
from  simple  message  passing  since,  depending  on  implementation 
techniques,  the  location  of  these  variables  and  semaphores  may 
not  be  known  previous  to  run  time. 

e-  File/Data  Base  Management  (Figure  3-3).  The  system  must  have  a 
mechanism  by  which  data  generated  by  one  process  in  one  computer 
can  be  made  available  to  another  process  in  another  computer  when 
needed.  Appropriate  protection  mechanisms  must  be  implemented  to 
assure  proper  updating  of  data  and  the  avoidance  of  "deadly  embrace" 
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Figure  3-3.  File/Data  Base  Management  Control  Function  Hierarchy 

conditions;  for  example,  Process  A is  waiting  for  data  from  Process 
B,  which  is  waiting  for  data  from  Process  A.  In  addition,  all  global 
variables  and  semaphores  must  be  updated  and  made  available  to  all 
processes.  Reconfiguration  programs  and  control  data  must  be  avail- 
able for  use  if  required.  Finallv,  system  checkpoint  data,  status,  md 
configuration  must  be  maintained. 

f.  Synchronization.  As  in  the  local  control  mechanism,  tins  function  re- 
solves conflicts  that  mav  arise  when  two  or  more  processes  require 
the  use  of  a single  resource.  Semaphores  are  the  usual  mechanisms 
used  by  the  synchronization  function. 

g.  Dispatching.  This  function,  again  as  in  the  local  control  mechanism, 
determines  when  the  global  conditions  necessary  for  the  execution  of  a 
particular  process  have  been  satisfied. 

h.  Event  Coordination.  If  an  application  process  causes  an  event,  that 
event  is  normally  serviced  by  another  process.  It  is  the  responsibility 
of  the  event  coordination  function  to  see  that  this  second  process  is 
queued  for  dispatch  (regardless  of  where  it  is  in  the  system)  and  to 
pass  any  necessary'  messages  between  the  event-causing  process  and 
the  event- servicing  process. 
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SECTION  4 

.APPLICATION  STRUCTURE 

A set  of  application  DU's  and  the  functions  for  controlling  their  execution 
have  been  defined.  Now  implementation  techniques  must  be  developed  such  that 
these  functions  can  execute  and  perform  the  mission  optimally  with  respect  to  a 
set  of  predefined  assessment  criteria.  These  assessment  criteria  are  chosen 
according  to  the  demands  of  the  application. 

The  following  paragraphs  define  a very  high-level,  generic  structure  that 
will  act  as  a baseline  for  the  architecture.  Assessment  criteria  for  the  BASIC 
application  will  be  defined  and  justified,  and  implementation  techniques  for  the 
baseline  structure  will  be  recommended,  such  that  the  generic  structure  will 
become  better  defined  and  applicable  to  the  BASIC  mission. 

4.  1 BASELINE  GENERIC  STRUCTURE 

.An  avionic  system  can  generally  be  considered  as  an  application  function 
comprising  two  major  elements.  These  elements  include  a complement  of 
sensors  subsystems,  which  perform  the  search,  detection,  position  determina- 
tion, and  communication  functions  of  a mission,  and  a processing  system  ful- 
filling the  corresponding  information  processing  functions.  Figure  4-1  charac- 
terizes a generic  application  function  architecture  in  terms  of  sensor  subsystem 
elements,  processing  system  elements,  and  an  interconnection  structure. 

T.  O.  Wolff's  paper,  "Improvements  In  Real  Time  Distributed  Control" 
icontained  in  Reference  9),  indicated  that  there  are  only  four  basic  strategies  at  the 
the  disposal  of  system  architects  for  attaining  higher  performance. 

a.  Redefinition  of  the  problem  in  more  efficient  form  — algorithm  develop- 
ment 

b.  Development  of  functionally  specialized  machines 

c.  Improvement  in  raw  speed  of  components 

d.  Application  of  system  and  machine  architectures  which  support  concurrency 
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Since  the  first  two  strategies  depend  greatly  on  the  application,  the  gain  is 
moderate,  concentrating  on  only  a part  of  the  overall  system.  The  third  approach 
is  limited  by  the  state  of  the  art  in  solid-state  devices  at  any  point  in  time.  As 
a result,  the  immediate  goal  of  most  system  architecture  work  is  the  fourth  stra- 
tegy, that  is,  to  find  methods  of  multiplying  performance  by  creating  systems 
which  exploit  parallel,  concurrent,  or  simultaneous  execution  of  tasks  in  multi- 
ple processing  elements. 

The  architecture  depicted  in  Figure  4-1  is  organized  to  employ  multiple 
processing  elements  by  partitioning  the  processing  system  function  into  related 
task  groups.  The  interconnection  structure  provides  a mechanism  which  permits 
any  element  to  communicate  with  any  other.  As  implied  in  Figure  4-1,  growth 
in  the  sensor/subsystem  area  to  accommodate  technological  advances  or  1'esponses 
to  new  threat  conditions  should  only  have  impact  on  the  processing  system  by 
either  adding  subtasks  within  task  groups  or  adding  new  task  groups  and  making 
appropriate  adjustments  to  the  intereonnetion  structure. 

4.2  ASSESSMENT  CRITERIA 

Architectures  that  employ  multiple  processor  organizations  are  generally 
classified  as  distributed  systems.  Some  of  the  current  questions  pertinent  to  the 
expectations  of  distributed  systems  include  the  following: 

• Can  the  system  easily  adapt  to  new  functions? 

• Does  the  system  provide  ease  of  modular,  incremental  growth  and  con- 
figuration flexibility  for  both  hardware  and  software  ? 

• What  type  of  interconnect  and  control  structures  is  required? 

• How'  does  the  system  detect,  categorize,  isolate,  and  recover  from 
failures? 

In  view  of  these  and  other  concerns  regarding  distributed  processing  archi- 
tectures, this  section  attempts  to  establish  general  design  and  assessment  cri- 
teria guidelines  for  application  in  the  development  of  a multiple  processor 
organized  avionic  information  processing  system.  The  extent  to  which  the 
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potential  benefits  expected  of  distributed  processing  systems  can  be  realized 
depends  on  the  degree  to  which  the  subsequent  assessment  criteria  are  achieved. 

4.2.1  Flexibility 

In  the  literature,  system  flexibility  is  referred  to  by  various  terms,  such  as 
modularity,  expandability,  adaptability,  and  extensibility.  Essentially,  flex- 
ibility can  be  considered  to  be  the  ease  with  which  system  function  and  perform- 
ance can  be  changed  without  altering  the  basic  system  design. 

4.  2. 1.1  Design  Goals  for  Flexibility 

Although  implementing  the  mechanisms  to  achieve  the  desired  flexibility 
implied  in  Figure  4-1  is  subject  to  various  current  issues  regarding  multiple 
processing  systems,  the  generic  architecture  shown,  nonetheless,  serves  as  a 
model  that  is  suggestive  of  design  goals  for  which  to  strive.  An  ultimate,  overall 
objectiv  e is  to  derive  a single,  versatile  architecture  that  has  the  necessary  fea- 
for  potential  application  to  many  platforms.  Toward  this  end.  the  following- 
architectural  features  indicate  a design  philosophy  that  will  facilitate  system 
flexibility: 

a.  Technology  Adaptation.  The  architecture  should  accommodate  anv 
technological  improvements. 

b.  Standardization.  System  elements  should  be  standardized  to  the  greatest 
extent  practicable  for  increasing  interchangeability  and  commonality. 

c.  Interconnection  Structure.  The  number  of  hardware  resources  on  any 
bus  should  only  be  limited  by  the  data  transmission  capacity  of  the  bus. 

In  addition,  all  processors  in  the  system  should  be  able  to  communicate 
with  the  peripherals  of  any  other  processor  in  the  system  either  directly 
or  through  another  processor, 

d.  Task  Intercommunication.  Programs  from  an  auxiliary  memory  should 
be  capable  of  being  transferred  over  the  bus  structure  as  a regular  part 
of  an  executing  operational  program  without  degrading  the  overall  system 
operation. 

e.  Executive  Control  Structure.  The  system  executive  should  provide  an 
efficient  means  for  supporting  task  interaction  and  permit  ease  of 
modifying  the  applications  supported. 
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4.2. 1.2  Flexibility  Techniques 

As  indicated  previously,  Figure  4-1  depicts  the  general  characteristics 
necessary  for  achieving  system  flexibility.  Techniques  for  implementing  these 
characteristics  are,  however,  subject  to  many  architectural  and  application  con- 
siderations. The  architectural  modularity  aspect,  for  example,  must  be  accom- 
panied by  well-conceived  interfaces  for  hardware,  software,  communications, 
and  control  in  support  of  the  application  function  being  implemented.  Paragraph 

4.2. 1. 1 lists  several  features  that  are  desirable  for  enhancing  flexibility.  The 
following  paragraphs  provide  a further  discussion  of  these  features. 

4. 2. 1. 2. 1 Technology  Adaptation.  During  the  life  of  a system  there  will  be 
numerous  changes  in  the  nature  of  tactical  operations.  Some  of  these  changes 
may  result  from  changes  in  the  anticipated  threat  or  changes  in  tactics  used 
to  counter  existing  threats.  Certain  functions  w ithin  the  system  may  require 
updating  or  replacement  by  new  functions.  It  follows  that  the  processing  sys- 
tem design  must  be  able  to  accommodate  or  adapt  to  such  changes  in  function 
without  hardware  redesign  or  disruption  of  other  ongoing  functions  in  the  -•  -- 
tem.  This  implies  that  the  system  must  be  able  to  accommociate  software 
revision  and  the  addition  of  hardware  elements  without  any  changes  in  the  basic 
system  design. 

In  reference  to  Figure  4-1,  the  priority  of  approaches  suggested  to  accom- 
modate functional  changes  is,  first,  to  add  or  modify  subtasks  within  a task 
group  and  then  to  add  new  task  groups.  The  rationale  for  initially  evaluating 
the  addition  or  modification  of  subtasks  within  a task  group  is  to  minimize  ad- 
ditional hardware  and,  consequently,  interconnection  modifications.  However, 
given  a flexible  interconnection  structure,  the  addition  of  processor,  memory, 
or  I O channels  should  also  be  accomplished  with  relative  ease. 

4.2. 1.2.2  standardization.  Standardization  is  a desirable  feature  since  it  implies  a 
homogeneous  rather  than  a heterogeneous  architecture  and  is  conducive  to  simplifi- 
cation. The  prime  advantages  of  standardization  are  interchangeability  and 
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commonality,  since  the  numbers  of  different  types  of  elements  in  the  system  are 
minimized.  Of  course,  the  degree  to  which  standardization  can  be  incorporated 
is  subject  to  various  trade-offs. 

One  of  the  trade-off  decisions  with  respect  to  flexibility  is  where  to  concen- 
trate the  expandability  potential  of  processing  power.  Since  we  are  dealing  with  a 
multiple  processing  approach,  expandability  could  be  made  available  by  utilizing 
only  partial  capabilities  of  more  powerful  processors,  using  the  reserve  capa- 
bilities when  adding  more  tasks;  or  by  employing  less  powerful  processors 
tailored  to  particular  tasks  with  little  to  no  reserve  capabilities  and  adding 
processors  for  additional  tasks  when  required.  However,  for  complete  flexi- 
bility, provisions  should  be  made  for  accommodating  any  combination  of  the 
above  to  the  greatest  possible  extent. 

If  the  design  is  confined  to  the  constraints  of  current  Navy  standardization 
programs,  analysis  of  the  near-term  objectives  should  consider  architectures 
incorporating  elements  such  as  the  AN  AYK-14  computer  and  the  MIL-tTD-lo53A 
bus,  with  associated  executives.  For  the  long  term,  however,  the  architecture 
should  be  prepared  for  adapting  to  new  miniaturized  technologies,  such  as  iu- 
and  32-bit  microcomputers  as  well  as  fiber  optic  buses. 

4.2. 1.2.3  Interconnection  structure.  An  interconnection  structure  is  concerned 
with  the  bus  configuration  and  conventions  by  which  the  various  system  elements 
are  able  to  communicate.  The  set  of  rules  by  which  the  various  elements  of  the 
system  communicate  is  governed  by  the  protocol.  The  protocol  also  defines 
status  information  to  be  exchanged  and  maintains  coordination  between  various 
asynchronously  operating  functions.  For  multiple  processing  systems,  the 
manner  in  which  the  various  elements  are  connected  is  currently  referred  to  as 
coupling,  of  which  there  are  two  types.  Loose  coupling  is  generally  characterized 
by  disjoint  primary  address  spaces,  use  of  bit  serial  buses,  and  comparatively 
smaller  interprocess  communication  bandwidth,  where  communication  among 
distributed  elements  is  accomplished  by  message  passing.  Tight  coupling 
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4.2. 1.2  Flexibility  Techniques 

As  indicated  previously,  Figure  4-1  depicts  the  general  characteristics 
necessary  for  achieving  system  flexibility.  Techniques  for  implementing  these 
characteristics  are,  however,  subject  to  many  architectural  and  application  con- 
siderations. The  architectural  modularity  aspect,  for  example,  must  be  accom- 
panied by  well -conceived  interfaces  for  hardware,  software,  communications, 
and  control  in  support  of  the  application  function  being  implemented.  Paragraph 
4. 2. 1.1  lists  several  features  that  are  desirable  for  enhancing  flexibility.  The 
following  paragraphs  provide  a further  discussion  of  these  features, 

4.2. 1.  2. 1 Technology-  Adaptation.  During  the  life  of  a system  there  will  be 
numerous  changes  in  the  nature  of  tactical  operations.  Some  of  these  changes 
may  result  from  changes  in  the  anticipated  threat  or  changes  in  tactics  used 
to  counter  existing  threats.  Certain  functions  within  the  system  may  require 
updating  or  replacement  by  new  functions.  It  follows  that  the  processing  sys- 
tem design  must  be  able  to  accommodate  or  adapt  to  such  changes  in  function 
ithout  hardware  redesign  or  disruption  f other  ongoing  functions  in  the  sys- 
tem. This  implies  that  the  svstem  must  be  able  to  accommodate  software 
revision  anu  the  addition  of  hardware  elements  without  anv  changes  in  the  basic 
system  design. 

In  reference  to  Figure  4-1,  the  priority  of  approaches  suggested  to  accom- 
modate functional  changes  is,  first,  to  add  or  modify  subtasks  within  a task 
group  and  then  to  add  new  task  groups.  The  rationale  for  initially  evaluating 
the  addition  or  modification  of  subtasks  within  a task  group  is  to  minimize  ad- 
ditional hardware  and,  consequently,  interconnection  modifications.  However, 
given  a flexible  interconnection  structure,  the  addition  of  processor,  memory, 
or  I/O  channels  should  also  be  accomplished  with  relative  ease. 

4.  2. 1.2. 2 Standardization.  Standardization  is  a desirable  feature  since  it  implies  a 
homogeneous  rather  than  a heterogeneous  architecture  and  is  conducive  to  simplifi- 
cation. The  prime  advantages  of  standardization  are  interchangeability  and 
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commonality,  since  the  numbers  of  different  types  of  elements  in  the  system  are 
minimized.  Of  course,  the  degree  to  which  standardization  can  be  incorporated 
is  subject  to  various  trade-offs. 

One  of  the  trade-off  decisions  with  respect  to  flexibility  is  where  to  concen- 
trate the  expandability  potential  of  processing  power.  Since  we  are  dealing  with  a 
multiple  processing  approach,  expandability  could  be  made  available  by  utilizing 
only  partial  capabilities  of  more  powerful  processors,  using  the  reserve  capa- 
bilities when  adding  more  tasks;  or  by  employing  less  powerful  processors 
tailored  to  particular  tasks  with  little  to  no  reserve  capabilities  and  adding 
processors  for  additional  tasks  when  required.  However,  for  complete  flexi- 
bility, provisions  should  be  made  for  accommodating  any  combination  of  the 
above  to  the  greatest  possible  extent. 

If  the  design  is  confined  to  the  constraints  of  current  Navy  standardization 
programs,  analvsis  of  the  near-term  objectives  should  consider  architectures 
incorporating  elements  such  as  tne  AN  AYK-14  computer  and  the  MIL-STD-1353A 
bus,  with  associated  executives.  For  the  long  term,  however,  the  architecture 
should  be  prepared  for  adapting  to  new  miniaturized  technologies,  such  as  i<>- 
and  32-bit  microcomputers  as  well  as  fiber  optic  buses. 

4.2. 1.2.3  Interconnection  Structure.  An  interconnection  structure  is  concerned 
with  the  bus  configuration  and  conventions  by  which  the  various  system  elements 
are  able  to  communicate.  The  set  of  rules  by  which  the  various  elements  of  the 
system  communicate  is  governed  by  the  protocol.  The  protocol  also  defines 
status  information  to  be  exchanged  and  maintains  coordination  between  various 
asynchronously  operating  functions.  For  multiple  processing  systems,  the 
manner  in  which  the  various  elements  are  connected  is  currently  referred  to  as 
coupling,  of  which  there  are  two  types.  Loose  coupling  is  generally  characterized 
by  disjoint  primary  address  spaces,  use  of  bit  serial  buses,  and  comparatively 
smaller  interprocess  communication  bandwidth,  where  communication  among 
distributed  elements  is  accomplished  by  message  passing.  Tight  coupling 
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is  generally  characterized  by  shared,  directly  accessible,  executable  main  mem- 
ory', with  comparatively  higher  primary  memory  bandwidth  and  lower  inter- 
processor communication  latency. 

Referring  to  Figure  4-1,  the  circles  contained  within  the  interconnection 
structure  represent  coupling  mechanisms.  With  respect  to  flexibility,  although 
all  elements  are  shown  and  should  have  the  potential  for  being  connected,  the 
actual  connection  coupling  scheme  is  determined  by  information  flow  and  data 
rates  of  the  application.  Consider  a loosely  coupled  configuration  in  which  a 
bus  is  assumed  to  be  connected  to  all  elements  in  the  system,  and  designate  it 
to  be  a global  bus.  Provided  the  bus  bandwidth  is  adequate,  the  addressing 
capability  of  the  bus  should  be  able  to  access  all  elements,  with  provisions  to 
add  more.  Capability  should  also  be  provided  to  distribute  the  information  flow 
simultaneouslv  among  several  buses  to  accommodate  increased  loads. 

Provisions  for  schemes  should  also  be  devised  such  that  communication  can 
be  accomplished  on  a local  level  with  separate  buses,  so  that  the  global  bus  load 
can  be  relieved  and  still  maintain  indirect  communication  with  the  global  bus  to 
extent  necessary.  Depending  on  the  data  rates,  the  local  bus  structures  could 
also  be  loosely  coupled. 

The  choice  between  loose  and  tight  coupling  is  subject  to  a detailed  analysis 
of  the  projected  application  requirements,  but  implementation  of  both  should  be 
taken  into  consideration  for  flexibility  purposes.  From  a standardization  point 
of  view,  it  would  be  desirable  to  employ  one  type  of  bus  structure  in  an  incremental 
fashion  to  satisfy  application  requirements. 

4. 2. 1.2. 4 Task  Intercommunication.  In  a multiple  processing  architecture, 
tasks  will  be  distributed  among  various  processing  elements,  as  implied  in  Figure 
4-1.  Because  of  the  dependency  of  characteristic  functions  in  tactical  applica- 
tions, the  interaction  of  tasks  associated  with  other  processors  will  be  required 
in  addition  to  those  associated  with  a local  processor.  Certain  common  routines 
that  are  required  by  the  majority  of  tasks  may  not  be  replicated  in  all  processors 
but,  instead,  be  centralized  in  a globally  accessible  processor. 
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To  facilitate  flexibility,  the  location  of  resources  necessary  to  execute  a 
task  should  be  transparent  to  the  task.  This  implies  the  need  for  an  address 
translation  mechanism  which  coordinates  the  use  of  all  resources  by  task, 
including  the  processor  and  memory  to  which  it  is  assigned. 

4.  2. 1.2. 3 Executive  Control  Structure.  An  executive  is  concerned  with  a well- 
conceived  control  structure  that  is  capable  of  directing  all  system  resources  to 
interact  efficiently  in  accomplishing  the  overall  application  function.  The  ex- 
ecutive is  responsible  for  functions  such  as  the  scheduling  and  dispatching  of 
tasks,  resource  control,  task  intercommunications  and  control,  and  interrupt 
handling.  In  centralized  systems,  the  executive  control  structure  is  essentially 
associated  with  a single  processor.  However,  multiple  processing  system 
architectures  require  the  executive  as  well  as  the  tasks  to  be  distributed  among 
the  various  processing  elements. 

One  o!  the  current  issues  regarding  multiple  processing  architectures  is 
'-•’.at  ot  load  balancing.  For  purposes  ot  discussion,  load  balancing  can  be  con- 
sidered either  dynamic  or  static.  Dynamic  load  balancing  is  concerned  with  the 
dmamic  ior  automatic)  assignment  of  tasks  so  that  the  workload  is  as  equally 
distributed  as  possible  among  the  various  processors.  The  control  structure 
necessary  to  realize  this  type  of  architecture  is  extremely  complex  and  is  the 
subject  of  many  investigative  studies,  in  static  load  balancing,  on  the  other 
hand,  tasks  are  preassigned  to  specific  processors  at  system  generation  time, 
so  that  the  location  of  these  tasks  is  always  known.  The  only  time  tasks  are  re- 
assigned to  alternate  processors  is  after  failure  reconfiguration,  and  even  these 
assignments  are  deterministic.  The  control  structure  necessary  to  realize  this 
type  of  architecture  appears  to  be  less  stringent  than  the  dynamic,  because 
of  the  elimination  of  the  dynamic  workload  distribution  mechanism.  The  static 
load  balancing  approach  is  selected  for  deriving  the  architecture  in  this  report 
because  it  more  nearly  matches  the  nature  of  the  avionic  processing  problem  and 
because  it  presents  less  of  a run-time  burden  on  the  processing  system.  Other 
related  issues  concern  the  distribution  of  system-wide  control  and  the  mechanism 
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by  which  the  operational  integrity  of  the  system  is  assured  to  be  preserved. 

These  and  other  control  structure  design  aspects  are  discussed  elsewhere  in 
this  report. 

4.2.2  Fault  Tolerance /Recovery' 

4. 2.  2.1  Definition  of  Terms 

Fault  tolerance  is  an  attribute  of  an  information  processing  system  that  en- 
ables the  system  to  continue  expected  behavior  after  the  appearance  of  certain 
classes  of  faults  (physical,  man-made,  or  both)  that  would  otherwise  force  the 
system  into  an  error  state.  A fault  is  an  abnormal  condition  of  hardware,  soft- 
ware, or  data  that  may  cause  a deviation  from  the  expected  sequence  of  behavior 
of  some  part  of  the  system.  An  error  state  is  a system  state  that  can  lead  to  a 
failure  attributed  to  some  aspect  of  that  state.  Finally,  a failure  occurs  when 
a system  does  not  meet  its  specifications;  it  is  an  externally  observable  event. 

t.2.2.2  CT.t-ses  of  Faults 

There  are  a number  of  dimensions  by  which  faults  can  be  characterized; 
ar.on?  them  are  the  following: 

a.  Duration:  transient  versus  permanent 

b.  Extent;  local  versus  global 

c.  Value.-  determinate  versus  indeterminate 

d.  Criticality:  flight-critical  versus  mission-critical  versus  mission- 
degrading 

However,  during  the  succeeding  discussion,  we  shall  take  criticality  as  the  prime 
dimension  distinguishing  three  classes  of  faults  from  each  other,  that  is,  flight- 
critical  versus  mission-critical  versus  mission-degrading.  Examples  of  functions 
in  which  faults  would  be  in  the  three  classes,  respectively,  are  in-flight  perform- 
ance monitoring,  ordinance  management,  and  flight  recording.  Of  course,  it  is 
possible  for  a fault  to  affect  both  flight -critical  and  mission-critical  functions, 
for  example,  a fault  in  one  or  more  of  the  executive  functions,  such  as  inter- 
rupt handling  or  synchronization. 
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4. 2.  2. 3 Techniques  of  Fault  Tolerance 

There  are  six  areas  of  fault  tolerance  that  must  be  addressed:  (1)  prevention, 
i2)  masking,  (3)  detection,  (4)  diagnosis,  (5)  isolation,  and  (6>  recovery. 

4.  2.  2.3. 1 Fault  Prevention.  Included  in  this  area  would  be  the  practice  of 
such  software  techniques  as  top-down  design,  structured  programming,  careful 
debugging,  and  the  use  of  a higher  order  language.  In  hardware  the  designer 
should  ideally  use  reliable  components,  rigorous  quality  control,  nonvolatile 
memories,  and  careful  design  to  minimize  the  occurrence  of  faults. 

The  major  trade-off  decisions  to  be  made  by  a designer  in  the  area  of  fault 
prevention  are  degree  of  prevention  and  availability  versus  cost,  size,  weight, 
processing  time,  and  memory  requirement. 

4. 2.  2. 3. 2 Fault  Masking.  Fault  masking  uses  redundancy  to  assure  that  the 
effect  of  a fault  is  completely  contained  within  a system  module.  If  sufficient 
redundancy  exists  in  the  module,  which  may  be  either  hardware  or  software,  the 
fault  is  concealed  within  the  module;  and  no  effect  is  propagated  outside  the 
module. 

A key  issue  in  masking  is  the  size  of  the  module  within  which  masking  occurs. 
In  hardware,  the  masked  module  can  vary  from  a few  components  to  an  entire 
subsystem  or  processor.  Likewise,  in  software,  redundancy  can  be  built  into 
a relatively  small  module  or  into  a large  module. 

The  trade-off  design  decisions  to  be  made  in  this  area  are  the  same  as  in 
fault  prevention. 

4.  2.  2.3, 3 Fault  Detection.  Fault  detection  is  the  starting  point  of  most  fault  re- 
covery implementations.  It  can  be  accomplished  by  either  hardware  or  software 
methods,  which  can  be  grouped  according  to  the  time  of  their  application; 

a.  Initial  testing,  which  takes  place  prior  to  normal  use  and  serves  to 
identify  fault  hardware  elements 
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b.  Concurrent  (on-line)  detection,  which  takes  place  simultaneously  with 
normal  operation  of  the  system 

c.  Scheduled  lOff-linet  detection,  which  takes  place  when  normal  operation 
is  temporarily  suspended 

d.  Redundancy  testing,  which  verifies  that  the  various  redundancy  features 
of  a system  are  ready  to  use  when  needed 

Issues  to  be  decided  by  the  designer  in  the  area  of  fault  detection  are  the 
following:  What  percentage  of  faults  is  to  be  detected?  With  what  level  of 
confidence?  Is  fault  detection  to  be  accomplished  by  hardware,  software,  or 
combination?  Which  of  the  four  above  tyoes  of  fault  detection  will  be  utilized? 

Naturally,  the  greater  the  level  of  fa,  detection  and  the  greater  the  level 
of  confidence,  the  more  elaborate  are  the  methods,  whether  hardware  or  software, 
which  must  be  used  to  settle  these  matters.  As  the  complexity  of  fault  detection 
rises,  the  availability  of  the  system  will  rise  tup  to  a pointi;  but  so  will  cost, 
size,  weight,  processing  time,  and  memory  requirements.  Beyond  a certain 
lev  el  of  fault  detection,  the  hardware  and  or  software  required  is  so  elaborate 
that  there  is  more  chance  of  a fault  occurring  in  the  detection  hardware  and  or 
software  than  in  the  equipment  being  tested. 

4. 2.  2. 3. 4 Fault  Diagnosis.  Fault  diagnosis  is  concerned  with  determining  the 
specific  nature  of  a fault  which  has  occurred  in  order  to  repair  it.  On-line  or 
off-line  diagnosis  during  flight  is  not  very  practical  for  many  avionic  processing 
systems  because  repairs  cannot  be  made  easily  during  a mission.  On  ship  or 
ground  or  on  large  aircraft,  such  as  the  P-3C,  fault  diagnosis  might  be  more 
practical. 

4. 2. 2. 3.. 5 Fault  Isolation.  Once  a fault  has  been  detected  and  localized  to  a 
specific  hardware  or  software  module,  the  failed  module  must  be  isolated  from 
the  rest  of  the  system  to  avoid  propagating  erroneous  information  throughout  the 
system.  Issues  which  the  designer  must  decide  are  how  large  the  modules  should 
be  ifor  example,  should  a hardware  module,  for  the  purposes  of  fault  isolation, 
be  a processor  or  a section  of  a processor)  and  when  a module  should  be  isolated 
tafter  the  first  detection  of  failure  or  after  several  attempts  to  get  the  module 
to  respond). 
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4. 2. 2. 3.  6 Fault  Recovery.  Fault  recovery  comprises  all  actions  taken  after  a 
fault  has  been  detected  and  the  failed  unit  has  been  isolated  to  restore  some 
degree  of  normal  operation  in  the  system.  Recovery  algorithms  can  be 
divided  into  automatic  and  manually  controlled  schemes.  Manual  schemes  are 
usually  not  too  feasible  for  avionic  use,  except  possibly  for  large  aircraft  such 
as  the  P-3C,  because  flight  personnel  do  not  have  the  time  or  knowledge  to  re- 
configure a processing  system  and  because  of  space  and  weight  constraints  in 
the  plane. 

Automatic  schemes  can  be  subdivided  into  three  classes:  full  recovery, 
partial  recovery,  and  safe  shutdown.  Full  recovery-  means  that  the  system  is 
restored  to  the  same  capability  that  existed  before  the  fault.  Failed  hardware 
is  replaced  by  spares;  damaged  programs  and  data  are  returned  to  a state  existing 
before  the  fault.  Partial  recovery  (also  known  as  degraded  recovery,  graceful 
degradation,  or  fail-soft  operation*  returns  the  system  to  a fault-free  state  but 
" ith  reduced  capability.  This  means  that  some  hardware  modules  have  been 
eliminated  from  the  system  without  replacement,  some  functions  and  or  data 
have  been  lost,  or  some  functions  now  take  longer  or  arc  performed  less  frequent- 
ly than  scheduled.  Safe  shutdown  also  called  fail-safe  operation*  is  the  limiting 
case  of  partial  recovery.  It  is  used  when  the  remaining  processing  eapability 
is  below  a minimum  acceptable  threshold.  The  goals  of  safe  shutdown  are  to 
avoid  damage  to  the  remaining  good  programs,  data,  and  hardware;  to  cease 
interactions  with  other  systems  and/or  operators;  and  to  deliver  shutdown  mes- 
sages and  diagnostic  information  to  designated  users. 

Hardware-controlled  systems  use  dedicated  hardware  to  detect  the  presence 
of  a fault  and  to  initiate  recovery-,  while  software-controlled  systems  use  special 
programs  to  accomplish  this. 

The  principal  advantage  of  hardware  -controlled  recovery-  systems  lies  in 
their  independence  of  the  operation  of  software  immediately  after  the  fault  has 
occurred.  Recovery-  control  is  transferred  to  software  only  after  the  software's 
ability  to  operate  has  been  assured.  The  major  disadvantage  is  that  special  hard- 
ware must  be  designed,  built,  and  maintained. 
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The  major  advantage  of  software -controlled  recovery  systems  is  that  existing 
hardware  modules  can  be  used,  with  resultant  increased  reliability  and  lower 
life-cycle  cost.  The  major  limitation  is  that  the  recovery  must  remain  opera- 
tional during  the  occurrence  of  a fault,  since  recovery  cannot  occur  unless  the 
recovery  software  can  run  correctly. 

4.  2.  2. 4 Detection  and  Recovery  Goals 

The  following  is  a list  of  goals  deemed  appropriate  for  the  BASIC  processing 
architecture  study: 

a.  100-percent  detection  of  all  faults  with  a 100-percent  confidence  level 

b.  Isolation  of  all  failed  units  from  the  system 

c.  Complete  recovery  from  fault(S)  in  one  or  two  flight -critical  functions 

d.  Complete  recovery  from  fault(s)  in  one  mission-essential  function 

e.  Partial  recovery  to  degraded  mode  of  operation  from  faults  of  two 
mission-essential  functions 

f.  Operation  in  degraded  mode  when  t'aultisi  occur  in  mission-degradable 
functions,  with  loss  of  only  those  functions 

4.  2.  2. 3 Design  Criteria 

The  criteria  used  in  making  decisions  on  the  choice  of  fault  tolerance  schemes 
are  the  following: 

a.  Availability  (including  fault  recovery  goals) 

b.  Life-cycle  cost 

c.  Use  of  standard,  off-the-shelf  hardware 

d.  Number  of  processors  and  processing  time  required 

e.  Memory  storage  requirements 

f.  Bus  requirements  (especially  data  transfer  rates) 

g.  Implementation  (hardware /software /firmware) 

h.  Reliability  (both  hardware  and  software) 

i.  Control  (hardware  or  software) 


4-13 


NADC-79161-40 


j.  Degree  of  recovery  and  functions  involved 

k.  Diagnostic  test  in  hardware,  software,  or  firmware 

l.  Type  of  fault  detection 

4.2.3  Recovery  Techniques 

As  described  in  paragraph  4.2.2,  recovery  from  a fault  must  be  preceded  by 
detection  of  the  fault  and  isolation  of  the  fault  to  a system  component  so  that  the 
rest  of  the  system  is  not  affected.  .After  these  actions,  recovery  may  be  obtained 
through  the  use  of  redundant  hardware  or  software,  or  through  the  operation  of 
the  system  in  a degraded  mode.  The  objective  of  this  paragraph  is  to  recommend 
the  best  techniques  for  the  implementation  of  these  recovery  functions  in  the 
BASIC  information  processing  system,  considering  the  constraints  imposed  bv 
the  state-of-the-art  and  the  use  of  standard  hardware  and  software. 

p 4. 2. 3.1  Detection  Isolation  Techniques 

Detection  of  faults  and  their  isolation  to  a particular  physical  module  :s 
accomplished  bv  performing  a test  on  the  module  and  comparing  the  module 
output  against  previously  defined  values.  This  comparison  can  indicate  whether 
the  module  is  functioning  properly  and  could  also  be  used  to  determine  which 
submodule  is  malfunctioning  or  which  group  of  further  tests  should  be  performed 
to  isolate  the  fault  to  a particular  submodule.  These  comparisons  can  be  made 
by  either  the  module  under  test  (seif-test)  or  some  other  module.  If  self-test 
is  used,  care  must  be  taken  that  the  comparison  mechanism  is  working  properly 
before  more  complex  tests  are  made. 

As  has  been  described  in  paragraph  4.2.2,  there  are  four  types  of  tests  that 
are  appropriate  for  the  testing  of  avionic  functions.  They  are  described  in  detail 
below. 

4.2.3. 1. 1 Initialization  Testing.  Initialization  testing  is  performed  when  the 
avionic  system  is  first  powered  up  prior  to  takeoff.  This  testing  may  also  be 
performed  as  a confidence  check  after  a system  reinitialization  following  a 
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failure.  Since  this  testing  time  is  not  critical  and  the  resources  to  be  tested 
are  not  required  for  other  functions  at  the  time  of  initialization,  initialization 
testing  should  be  the  most  complete  of  all  the  types  of  testing;  all  other  tests 
should  be  a subset  of  the  initialization  tests.  These  tests  must  be  sequenced 
in  such  a manner  that  very  simple  tests  on  very  basic  functions  are  tested  first. 
With  these  basic  functions  verified,  more  complex  tests  can  be  made  on  higher 
level  functions.  This  process  can  continue  until  very  complex  system  level 
tests  are  made  with  confidence  that  the  testing  mechanism  itself  is  in  good  work- 
ing order.  In  addition,  in  a system  like  BASIC,  these  tests  may  be  performed 
using  an  external  computer  and  other  test  equipment  which  are  not  part  of  the 
simulated  avionic  system.  This  can  provide  a significantly  greater  level  of 
confidence  in  the  testing  than  can  be  attained  simply  by  using  the  operational 
equipment. 

4. 2. 3. 1.1.1  Detection  Capability  Confidence  Level.  The  initialization  test 
should  be  the  most  complete  test  and  should  check  for  all  faults.  ,U1  flight- 
critical  faihwes  should  be  detected  with  a 100-percent  confidence  level.  For 
initialization  testing,  isolation  of  a fault  in  a particular  module  with  a great 
degree  of  precision  Is  not  necessary,  but  detection  of  any  fault  that  might 
jeopardize  the  continuation  of  the  mission  is  mandatory.  In  addition,  all  mission- 
critical  faults  should  be  detected  with  a high  degree  ( approximate! y 95  percenti 

of  confidence,  since  time  and  money  would  be  wasted  by  taking  off  and  not  being 
able  to  perform  the  intended  mission. 

4.2.3. 1.1.2  Hardware  Test  Functions.  Certain  of  the  initialization  tests  must 
be  implemented  in  hardware /firmware,  since  they  must  be  performed  in  order 
to  verify  the  proper  execution  of  software.  These  tests  must  check  the  ability 
of  a processor  to  read  and  write  memory  and  to  communicate  to  the  outside 
world  through  at  least  one  I/O  channel,  through  which  further  software  may  be 
loaded.  This  involves  the  self-check  of  many  data  paths  and  control  mechanisms 
which  are  best  tested  through  the  use  of  the  special  microcode  incorporated  into 
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the  firmware  of  the  computer.  This  section  of  microcode  is  entered  automati- 
cally on  power-on  condition,  and  it  includes  a capability  of  automatic  loading  of 
memory  from  an  I/O  channel  after  the  self -check  functions  are  complete. 

4. 2. 3. 1.1. 3 Software  Test  Functions.  After  software  is  loaded  into  the  computer 
memory,  a complete  diagnostic  test  program  may  be  run.  This  normally  starts 
with  a test  of  the  individual  instructions  and  ends  with  a test  of  the  interrupt 
structure.  At  this  point,  the  capability  to  transmit  and  receive  data  from  exter- 
nal  I O channels  can  be  tested.  In  the  case  of  the  MIL-STD-1553  bus,  this  capa- 
bility could  be  attained  by  having  the  computer  attempt  to  send  a prespecified  test 
message  to  itself. 

After  each  computer  has  completed  the  above  tests,  the  intercomputer  and 
computer-peripheral  communication  paths  may  be  tested.  .After  this,  system 
status  may  be  determined  and  reported;  this  step  completes  the  initialization 
testing. 

4.  2.3. 1.2  On-Line  Detection.  On-line  detection  is  performed  concurt'ently  with 
the  execution  of  application  processes.  It  normally  checks  the  validity  of  data 
passing  from  one  computer  to  another  or  from  one  segment  of  the  computer  to 
another.  It  also  can  be  useci  to  determine  if'  a particular  event  has  taken  place 
within  a specific  time  period.  Normal  implementation  of  on-line  detection  in- 
volves hardware  parity  checking  and  time-out  interrupts.  Time-out  interrupts 
occur  when  an  application  process  does  not  reset  a test  timer  within  a prespeci- 
fied interval.  Thus,  if  a process  is  in  an  infinite  loop  because  of  some  hardware 
or  software  failure,  a built-in  test  will  indicate  a failure. 

4. 2. 3. 1.2.1  Detection  Capability  Confidence  Level.  Since  on-line  detection  is 
basically  a built-in-test  concept,  the  detection  capability  and  confidence  levels 
for  it  depend  on  the  state  of  the  art  and  the  cost  weight  performance  penalties 
that  the  computer  designer  is  willing  to  accept.  For  the  most  part,  especially 
with  standard  hardware,  these  factors  are  beyond  the  control  of  the  system 
designer.  Most  military  computers  have  on-line  fault  detection  capability  in 
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compliance  with  the  requirements  of  AR-10.  Fault  isolation  capability  is 
usually  limited  to  an  indication  of  a fault  in  the  entire  computer  rather  than 
in  a particular  module. 

4. 2.3. 2 Isolation  Techniques 

Once  a fault  is  detected  and  isolated  to  a single  physical  module  or  set  of 
modules,  the  system  must  be  protected  from  the  effect  of  that  fault  by  the  iso- 
lation of  the  faulty  module  from  the  system.  For  the  purposes  of  this  discussion, 
assume  that  a fault  has  been  detected  and  isolated  to  one  of  the  following  units;  the 
central  processing  unit,  memory  module,  I/O  channel,  or  I/O  processor. 

4.  2. 3. 2.1  Central  Processing  Unit  iCPl'i  Faults.  If  only  one  CPU  exists  in 
the  computer  and  that  CPU  or  any  of  its  interfaces  to  the  rest  of  the  computer 
fails,  then  the  only  feasible  approach  to  isolation  is  to  disable  the  entire  com- 
puter and  remove  the  CPU  from  any  of  the  interface  buses  with  which  it  communi- 
cates. In  a well-designed  computer,  this  mav  be  easilv  accomplished  bv  removing 
power  from  the  computer.  This  removal  of  power  can  be  triggered  bv  a self-test 
signal  or  by  a signal  from  an  operator  or  an  external  hardware  monitor. 

In  a computer  which  has  multiple  CPU's,  such  as  a multiprocessor,  or  ■>  b.ich 
has  an  independent  I O processor,  it  may  be  possible  to  disable  only  the  faulty 
CPU  and  have  the  remainder  of  the  computer  act  as  a uniprocessor.  This  ca- 
pability would  have  to  be  designed  into  the  hardware  and  activated  either  by  a 
self-test  output  or  an  external  signal 

4. 2.  3.  2. 2 Memory  Module  Faults.  Faulty  memory  modules  can  be  isolated  from 
the  remainder  of  the  system  if  some  type  of  virtual  memory  translation  hardware 
is  incorporated  into  the  computer.  If  redundant  memory  is  available,  this  can  be 
substituted  for  the  faulty  physical  memory  module  by  aporopriate  changes  to  the 
virtual -to-physical  address  translation  tables.  If  redundant  memory  is  not  avail- 
able, it  may  be  possible,  through  memory  protection  mechanisms,  to  cause  an 
interrupt  if  an  attempt  is  made  to  reference  the  faulty  memory  module. 
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4.  2. 3.  2. 3 I/O  Channel  Failure.  If  an  I/O  channel  fails,  all  communication  between 
that  channel  and  the  CPU  or  memory  must  be  inhibited.  This  inhibition  can  be 
accomplished  by  changing  the  address  of  the  channel  to  an  unused  I 'O  channel 
address  or  by  using  a hardware  mechanism  that  essentially  switches  the  failed 
channel  off  and  replaces  it  with  a redundant  channel. 

4.  2. 3. 2. 4 I/O  Processor  (IOP)  Failure.  If  an  I/O  processor  fails  in  a computer 
which  has  a CPU  capable  of  performing  I/O  and  CPU  tasks  in  a time-shared  mode 
tas  in  the  case  for  the  AN/AYK-14),  then  the  IOP  may  be  shut  down  via  a mode 
command  and  the  computer  will  still  be  able  to  perform,  although  with  reduced 
performance.  If  the  CPU  cannot  perform  I/O  tasks,  then  the  entire  computer 
would  have  to  be  shut  down. 

4.  2.3.3  Recovery  Techniques.  Once  a faulty  module  has  been  isolated  from  the 
system,  steps  must  be  taken  to  recover  the  functional  capability  that  had  been 
impaired  by  the  fault.  If  this  is  not  possible,  then  the  system  must  be  recon- 
figured such  that  the  loss  of  that  function  uoes  not  cause  other  functions  to  fail. 

4. 2. 3. 3.1  Full  Recovery.  If  a fault  in  hardware  is  to  be  completely  masked, 
then  redundant  hardware  or  unused  time  resources  must  be  employed.  This 
process  may  be  implemented  with  redundant  computers  in  the  svstem  (which  may 
be  used  for  testing  in  a normal,  fault-tree  system/  and  possibly  with  unused 
memory  and  I O modules  in  the  operational  computers.  If  a CPU  fails  and  re- 
moval of  a computer  from  the  system  is  necessary,  then  its  replacement  must 
be  a computer  that  has  access  to  all  the  programs  executed  by  the  faulty  computer, 
and  all  the  constant  and  global  data  used  by  it.  These  programs  and  constant 
data  could  be  prestored  in  the  redundant  computer  or  stored  in  a mass  memen- 
to which  the  backup  computer  has  access.  Global  data  could  be  obtained  from 
other  processing  elements.  The  replacement  computer  must  have  access  to  all 
the  peripherals  and  other  system  processing  elements  with  which  the  original 
computer  communicated.  Under  these  conditions,  full  recovery  is  possible.  The 
faulty  computer  is  shut  down.  The  replacement  is  loaded  with  the  appropriate 
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programs  and  data,  is  initialized,  and  brought  into  operation  at  the  beginning  of 
the  next  major  cycle.  Thus,  processing  capability  and  data  are  lost  for  only  a 
short  time,  at  least  from  the  operator's  viewpoint. 

Because  a memory  module  may  fail,  an  extra  memory  module  in  the  computer 
is  necessary;  it  may  be  substituted  for  the  failed  module  by  changing  the  virtual-to- 
phvsical  address  translation  tables.  If  the  failed  module  contained  programs  or 
constant  data,  the  replacement  must  be  reloaded  with  this  information  from  an 
external  source,  on  the  data  must  have  been  prestored  in  the  redundant  module. 

If  an  I O channel  fails,  complete  recovery  requires  that  an  identical,  redun- 
dant channel,  connected  to  the  same  peripherals,  be  available.  In  this  case, 
switching  channels  is  normally  a simple  matter. 

If  an  1/ O processor  fails,  a redundant  IOP  \iust  be  available  within  the 
computer,  along  with  a hardware  mechanism  to  switch  out  the  failed  IOP  and 
replace  it  with  the  redundant  module.  This  is  not  normally  the  case  in  most 
computers,  -a  id;  the  result  that  complete  recovery  from  an  IOP  failure  must  be 
handled  by  replacement  of  the  entire  computer,  as  if  the  CPU  had  tailed. 

4.  2.  t'.  2 Partial  Recover"  'Graceful  Pear?.' ration • . Partial  recovery  usually 

means  that  full  recovery  is  not  possible  because  the  necessary  redundant  resources 

are  not  available.  In  this  case,  the  computer  which  has  suffered  the  failure  is 
shut  down,  and  its  tasks  are  assigned  as  extra  duties  to  another  operational  com- 
puter. This  backup  computer  must  have  access  to  the  same  peripherals  and 
system  elements  as  the  original.  Since  the  backup  computer  must  now  perform 
extra  processing,  more  time  will  be  required  to  execute  all  the  processes.  Since 
tasks  are  normally  dispatched  on  a priority  basis,  some  lower  priority  tasks 
may  not  be  executed  during  some  major  cycles.  If  this  condition  is  not  acceptable, 
some  tasks  may  be  given  variable  priority,  such  that  their  dispatching  priority 
increases  every  time  they  are  not  executed  during  a major  cycle.  Thus,  grace- 
ful degradation  for  a processing  system  essentially  means  that  lower  priority 
tasks  do  not  execute  as  often  as  the  system  specification  wou.d  require.  This 
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technique  is  clearly  not  acceptable  for  flight -critical  functions;  it  is  useful  for 
operator  display,  navigation,  and  communication  functions. 

4.  2.3. 3. 3 Safe  Shutdown.  Shutting  down  a function  is  necessary  when  a failure 
occurs  in  a module  for  which  there  is  no  backup  or  redundant  hardware  provided. 
This  normally  occurs  when  a mission  sensor,  such  as  a radar  transmitter  or  a 
MAD  receiver,  fails.  In  this  case,  the  scheduling  procedure  must  be  revised 
so  that  the  tasks  using  these  data  are  not  executed.  Periodic  tasks  that  process 
the  data  to  or  from  the  failed  sensor  should  not  be  executed,  and  demand  tasks 
that  require  these  data  should  be  replaced  with  processes  that  return  an  indica- 
tion that  the  required  function  has  failed. 

4.2.4  Software  Considerations 

Several  recent  studies  have  indicated  that  software  is  the  major  contributor 
to  overall  svstem  cost,  and  projections  are  that  the  cost  of  software  will  be 
:.o  nercent  v svstem  cost  bv  lOAt,  These  projections  may  very  well  prove  true, 
since  technological  improvements  in  hardware,  such  as  verv  large-~cale  inte- 
gration (VLSI),  have  produced  drastic  decreases  in  the  cost  of  hardware.  Such 
new  memorv  technologies  as  magnetic  bubbles  al=o  give  promise  of  substantially 
reducing  the  cost  of  memorv. 

Technological  progress  has  also  been  made  in  software  in  recent  vears  New 
developments  in  software  give  some  Dromise  of  keeping  software  costs  under 
control,  although  not  to  the  same  extent  as  in  hardware.  Such  developments  as 
higher  order  languages,  ton-down  design,  structured  programming,  and  modular 
programming  are  examples  of  these. 

4. 2. 4.1  Higher  Order  Languages 

The  advantages  of  using  a higher  order  language  (HOL)  for  application  Dl's 
implemented  in  software  are: 

a.  Shorter  programming  time 

b.  Shorter  debugging  time 
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c.  Lower  programming  cost 

d.  Increased  programming  transparency  (that  is,  the  ability  to  write  pro- 
grams without  need  for  detailed  knowledge  of  the  system i 

e.  Increased  portability  of  software  (that  is,  the  ability  to  use  software  on 
several  different  hardware  systems  with  only  minor  changes  required) 

The  disadvantages  are  that  the  HOL  may  result  in  a less  efficient  code  with 
more  processing  time  and  more  memory  required.  However,  the  advantages  of 
using  an  HOL  seem  to  outweigh  the  disadvantages,  especially  if  a standard  HOL 
is  used. 

4. 2. 4. 2 Top-Down  Design 

The  approach  being  used  to  design  the  BASIC  laboratory  information  process- 
ing system  is  a top-down  methodology  in  which  the  designer  starts  with  the 
application  requirements  and  works  down  fi-om  there  through  decomposition,  and 
so  forth.  This  methodology  is  somewhat  different  from  the  current  approaches 
in  kich  functions  are  assigned  for  implementation  in  software  at  the  beginning 
of  software  design.  Instead,  the  top-down  methodology  ,nes  not  choose  a medium 
for  implementation  imtil  'veil  along  in  the  design  process.  However,  this  nethod- 
ology  loe~  support  top- Awn  lesigr.  f softwar  e >nce  the  iecisi  n implement 
a particular  DC  in  software  is  made,  a top-do'vn  iesign  of  the  software  for  that 
DU  can  easily  be  attained,  with  all  of  the  functional  elements  iDE'S)  known  from 
previous  steps. 

4.2.4..',  Structural  Modular  Programming 

The  advantages  of  structural  modular  programming  are  the  following: 

a.  Supports  and  facilitates  top-down  design 

b.  Allows  proof  of  correctness.  The  only  way  to  be  certain  that  a software 
program  functions  properly  is  by  establishing  a "proof  of  correctness.  " 
Debugging  only  shows  the  presence  of  errors  and  not  their  absence  and, 
hence,  is  insufficient.  In  general,  a large  software  program  is  not 
amendable  to  such  a proof,  but  a smaller  module  is. 

c.  Reduces  programming  cost.  Figure  4-2,  taken  from  a General  Electric 
brochure,  show  s that  programming  cost  varies  exponentially  with  size  of 
program.  Therefore,  breaking  software  into  modules  should  reduce  costs. 
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NUMBER  OF  INSTRUCTIONS 


Figure  4-2.  Software  Size  Cost 


d.  Facilitates  software  management,  design,  maintenance,  and  verifi- 
cation by  easier  reading  of  code 

e.  .Ulo"  5 use  of  standard  or  common  modules  resulting  in  increased 
cost  effectiveness 

f.  Allows  flexibility  in  assignment  of  tasks  to  processors,  in  recovery 
after  a fault,  and  in  changing  the  system  for  various  applications 

g.  Facilitates  system  growth  by  allowing  new  functions  to  be  added 
relatively  easily 

h.  Promotes  portability  of  software 

i.  Meshes  well  with  the  XAVAIRDEVCEN  i'nivac  Design  Methodology 

The  possible  disadvantages  of  structured/modular  programming  are  that 
more  initial  programming  time  may  be  required,  and  that  the  code  generated 
may  demand  a slightly  longer  processing  time  and/or  slightly  more  memory. 
However,  the  advantages  more  than  outweigh  the  disadvantages. 
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■4.2.3  Compatibility  with  Hardware 'Software  Standards 

4.2.5. 1 Current  Applicable  Directive  and  Standards 

Among  the  current  directives  applicable  to  the  design  and  development  of 
computer  processing  systems  are  DoD  Directives  5000.29,  which  covers  the 
management  of  software,  5000.31,  which  specifies  the  acceptable  higher  order- 
languages  (HOL's),  and  5000. xx  (draft),  which  specifies  the  approved  computer 
architectures.  In  addition,  a memorandum  of  30  March  1977  from  the  Secretary 
of  the  Navy  specifies  that  the  AN  AYK-14  shall  be  the  Navy  standard  airborne 
computer.  The  AN  AYK-14  computer  includes  the  AX  UYK-20  instruction  set 
and  emulates  the  latter's  architecture. 

The  current  standard  Navy  HOL's  are  the  CMS-2  for  data  processing  and 
SPL-1  for  signal  processing,  with  DoD-1  to  be  the  future  DoD  standard  HOL. 

Other  existing  standards  specify  the  MIL-STD-1553,  -1553 A,  and  -1553B  buses 
as  the  standard  Navy  avionic  buses.  No  standard  microprocessor  has  vet  been 
chosen,  nor  is  there  a policy  for  standardization  in  the  areas  of  computer  resi- 
dent memories  or  mass  memory  storage. 

4. 2. 5. 2 Discussion 

Implementation  of  DU's  in  hardware  and  software  should  be  in  compliance 
with  existing  DoD  and  Navy  directives  and  standards  unless  there  is  some  com- 
pelling reason  to  request  a waiver.  The  purpose  of  such  documents  are  to  mini- 
mize the  proliferation  of  hardware,  increase  the  portability  of  software,  reduce 
logistic  requirements,  and  reduce  life-cycle  costs. 

The  disadvantage  of  standardization  is  the  difficulty  of  incorporating  the  latest 
technological  advances  (hardware  and  software!  when  processor  architecture, 
language,  bus  protocols,  and  so  forth  are  fixed.  In  Naval  avionic  applications, 
however,  the  advantages  of  standardization  over  an  "equipment  generation"  out- 
weigh the  disadvantages;  therefore,  standardization  will  be  followed  to  the  maxi- 
mum extent  possible. 
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APPLICATION  BINDING 


5.1  INTRODUCTION 

The  previous  sections  have  defined  a set  of  application  requirements,  broken 
those  requirements  into  decompositional  elements  (DE's),  combined  the  DE's 
into  decompositional  units  (DCs),  and  defined  a baseline  structure  within  which 
the  DCs  can  execute  their  functions.  The  next  step  in  the  architectural  develop- 
ment is  the  selection  of  implementation  media  for  the  DU's  and  the  composition 
of  these  implementations  into  an  overall  system.  This  section  will  develop  im- 
plementations for  the  DU's,  propose  a BASIC  system  architecture,  and  present 
the  rationale  for  the  selections  recommended.  Specific  areas  to  be  discussed 
are: 

• Information  Flow  — a description  of  data  flow  among  DU's  based  on  the 
S-3A  operational  program 

• DU  Functional  Grouping  — combining  DU's  into  functional  groups  for 
distribution  among  processing  nodes  for  the  BASIC  application 

• Message  Structure  — organizing  information  flow  and  defining  messages 
which  conform  to  the  MIL-STD-1553  bus  protocol  for  the  BASIC  applica- 
tion 

• Hardware  Configuration  — hardware  required  to  implement  the  proces- 
sing nodes 

• Processing  Requirements  — software  execution  parameters  corres- 
ponding to  the  various  DU's  to  be  simulated  in  the  BASIC  application 

• Control  Structure  — control  mechanisms  necessary  for  control  of  the 
DU's  and  a recommended  implementation  for  the  control  mechanisms. 

An  analytical  approach  was  employed  in  the  development  of  this  preliminary 
architecture.  This  implies  that  a simulation  remains  to  be  performed  via  the 
Generalized  Computer  System  Simulator  (GCSS)  so  that  the  architecture  recom- 
mended herein  can  be  verified  in  terms  of  interactions  between  the  data  transfers 
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and  the  processes  that  use  the  data.  A CCSS  simulation  is  currently  under 
development;  the  results  will  be  described  in  a future  supplement  to  this  report- 
s' D E C OM  POSIT  ION  A L UNIT  IMPLEMENTATIONS 

Having  defined  the  DU's,  it  now  becomes  necessary  to  select  an  implementa- 
tion medium  for  each  DU  in  a manner  which  will  optimize  the  assessment  cri- 
teria parameters  defined  in  Section  4.  In  all  cases,  a software  implementation 
was  chosen.  The  rationale  for  this  choice  with  respect  to  the  assessment  cri- 
teria is  presented  in  the  following  paragraphs. 


5.2.1  Flexibiiit 


DU’s  implemented  in  hardware  or  firmware  are  considerably  more  difficult 
to  change  than  DU's  implemented  in  software.  In  addition,  software  DU’s  can 
take  advantage  of  the  rapid  increases  in  hardware  performance  which  accompany 
processor  technology  growth.  Thus,  replacement  of  a computer  (which  executes 
many  DU’s)  with  a higher  performance  computer  automatically  increases  the 
performance  of  those  DU's. 

<5. 2.2  Fault  Tolerance/ Recovery 

It  is  assumed  that  software  errors  will  be  minimized  by  proper  programming 
practices,  simulation,  bench  testing,  and  flight  testing.  In  the  proposed  archi- 
tecture, failures  in  the  computing  hardware  on  which  the  DU's  execute  do  not 
result  in  loss  of  the  DU  function,  since  the  software  may  be  executed  (perhaps 
in  a degraded  mode)  in  a different  computer.  This  functional  redundancy  of  DU’s 
would  not  be  possible  in  hardware  implementation,  since  it  would  result  in  un- 
acceptable weight  and  cost  penalties  in  redundant  hardware. 

5.2.3  Software  Considerations 

The  DU's  can  be  programmed  in  HOL  and,  thus,  take  advantage  of  the  in- 
herent cost  savings  in  a modular,  structured  programming  approach.  Since  the 
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DU's  are  a result  of  a top-down  partitioning  methodology,  their  specifications 
and  interfaces  are  known  in  a format  highly  compatible  with  a computer  program 
performance  specification.  Indeed,  the  software  module  specifications  are 
very  nearly  a by-product  of  the  methodology  process. 

5.2.4  Compatibility'  With  Software/Hardware  Standards 

A DU  implementation  in  software  can  be  made  completely  compatible  with 
existing  standards.  No  unique  or  new  hardware  need  be  procured,  and  no  non- 
standard languages  need  be  used. 

5.3  DEC OM POSITIONAL  UNIT  FUNCTIONAL  GROUPING 

In  deriving  a multiple  processing  system  architecture,  it  is  necessary  to 
organize  the  DU's  shown  in  Figure  5-1  into  operational  groups  with  functions 
related  according  to  a set  of  assessment  criteria  so  that  they  can  be  distributed 
among  several  processing  elements  in  an  optimal  fashion.  However,  lacking 
weighting  parameters  and  associated  physical  assessment  criteria,  the  design 
decisions  for  grouping  DU's  in  the  recent  S-3A  architecture  study  were  essen- 
tially based  on  minimizing  I/O  rates  between  functional  groupings,  while  not 
exceeding  the  processing  capability  of  a moderate-power,  microprocessor- 
based  minicomputer. 

A DU  grouping  proposed  as  a result  of  the  study  described  in  Reference  4 
is  shown  in  Table  5-1.  In  addition  to  the  operational  DU's  shown,  allowances 
are  made  for  executive,  test,  and  diagnostic  functions.  The  executive  functions 
for  each  processor  differ  depending  on  the  scheduling  requirements  dictated  by 
the  particular  DU  group.  The  executive  function  overhead  is  currently  projected 
to  be  on  the  order  of  approximately  30  percent.  The  overhead  for  the  test  and 
diagnostic  functions  is  currently  estimated  as  being  less  than  10  percent.  The 
structure  of  the  executive  is  defined  in  more  detail  in  paragraph  5.5. 
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TABLE  5-1.  PROPOSED  DU  GROUPING 


PROCESSOR  GROUP 


' Mode  Control 
1 Data  Management 
1 Display  Control 
Frequency  Control 
Control 


1 Passive  Contact  Classification 
1 Passive  Contact  Maintenance 


1 Active  Ping  Control 
Active  Contact  Maintenance 


RADAR  Display  Control 
RADAR  Data  Management 


COMM  Receive 
COMM  Control 
COMM  Data  Management 
COMM  'transmit 


Aircraft  Steering  Control 

Weapon  Release 

Weapon  Drop-Point  Calculation 
Weapon  Selection 

X 

X 

X 

SRS  Control 

Sonobuoy  Position  Calculation 


Contact  Tracking 
Tactical  Coordination 


FLIR  Contact  Maintenance 
FLIR  Display  Control 
FLIR  Stabilization 
Executive 
Test/Diagnostic 
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5.4  DEC  OM  POSIT  ION  AL  UNIT/SUBSYSTEM  INFORMATION  FLOW 

The  partitioning  of  the  S-3A  operational  program  into  47  DU's  was  developed 
in  Section  3 and  is  summarized  in  Table  3-4  along  with  the  associated  sensors/ 
subsystems.  Figure  5-1  is  an  excerpt  from  Reference  3 which  shows  directional 
data  flow  paths  among  these  DU's  and  sensors/subsystems.  The  symbols  con- 
tained in  the  information  flow  diagram  of  Figure  5-1  are  interpreted  as  follows: 

• Boxes  represent  individual  DU's  whose  general  functions  are  described 
in  paragraphs  3. 2. 1. 2. 1 through  3.2.1.  2. 47  of  Section  3. 

• Oblong  circles  represent  elements  external  to  the  information  proces- 
sing system,  that  is,  sensors/subsystems. 

• Circles  with  the  letter  K indicate  data  obtained  from  the  Keyset  control 
element,  DU25. 

• Circles  with  the  letter  D indicate  display  data  (alerts,  cues,  and  so 
forth)  to  be  transferred  to  the  display  operator  control  element,  DU22. 

• Circles  with  the  letter  N indicate  navigation  data  (aircraft  position, 
speed,  course,  and  so  forth)  obtained  from  the  NAY  position  calculation 
element,  DU27.  As  indicated  previously,  each  DU  consists  of  a num- 
ber of  DE's.  These  DE's  are  the  next  lower  level  of  decomposition 
which  are  the  smallest  executable  entities  itasks).  However,  at  this 
time  the  S-3A  partitioning  at  the  DU  level  appears  to  provide  sufficient 
understanding  and  visibility  regarding  data  flow  and  element  interactions 
for  establishing  baseline  requirements  for  the  BASIC  avionic  informa- 
tion processing  system  architecture. 

5.5  DU/DU  COMMUNICATION 

Application  processes  will  be  distributed  among  various  processing  ele- 
ments in  a multiple  processor,  organized  information  processing  system.  This 
distribution  will  require  the  sharing  of  data  among  application  processes  and  is 
referred  to  as  communication. 

5.5.1  Modes  of  Communication 

For  purpose  of  discussion,  a process  can  be  considered  to  be  either  a data 
source  or  destination.  If  the  data  source  and  destination  processes  are  both  asso- 
ciated with  the  same  processor,  directly  accessing  the  same  memory,  then  the 
transfer  of  data  will  be  referred  to  as  intraprocessor  communication.  Lf  the  data 
source  and  destination  processes  are  associated  with  different  processors,  each 
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with  its  own  private  memory,  then  message  passing  is  required  to  move  the  data  to 
the  destination  process.  Data  transfer  employing  message  passing  will  be  referred 
to  as  interprocessor  communication. 

5.5.2  Address  Translation  Mechanism 

In  order  to  relieve  application  processes  from  the  concern  of  actual  data 
locations,  a communication  scheme  could  be  employed  in  which  address  trans- 
lation is  performed  by  a separate  mechanism.  This  scheme  will  be  referred  to 
as  an  address  translation  mechanism.  The  general  operation  of  the  proposed 
scheme  is  depicted  in  Figure  5-2.  As  shown,  data  locations  are  preassigned 
to  specific  groups  and,  from  the  point  of  view  of  the  application  process,  are 
always  directly  accessible.  In  operation,  when  the  application  process  proceeds 
to  fetch  data,  these  data  are  intercepted  by  the  address  translation  mechanism. 

This  mechanism  can  consist  of  a series  of  status  registers,  for  each  group  of 
data,  which  contain  flags  indicating  the  current  location  of  the  desired  data. 

When  employing  the  intraprocessor  communication  mode,  the  data  are  local  to 
the  process,  and  the  mechanism  immediately  proceeds  to  read  the  data.  When 
employing  the  interprocessor  communication  mode,  data  are  remote  to  the 
process,  and  an  I/O  mechanism  is  invoked  to  fetch  a copy  of  the  data.  After 
the  data  are  fetched,  the  status  is  changed  to  local,  the  processor  is  notified, 
and  the  process  continues.  A possible  implementation  of  the  mechanism  could 
invoke  an  interrupt-service  routine  to  initiate  the  necessary  I/O  procedures. 

Each  status  register  associated  with  a data  group  could  point  to  a location  in  a 
table  which  would  contain  the  appropriate  service  routine.  This  table  could  be 
defined  at  system  generation  time  with  provisions  for  modification  to  accommo- 
date system  reconfiguration. 

5.6  DATA/MESSAGE  MAPPING 

The  interaction  of  data  among  the  functions  of  the  processor  groups  shown 
in  Table  5-1  requires  the  use  of  an  interconnection/bus  structure  for  data  trans- 
fer. As  indicated  above,  two  types  of  data  transfers  will  be  considered:  intra- 
processor and  interprocessor  communications.  The  common  bus  structure  that 
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APPLICATION  PROCESS 

FETCH  DATA 


Figure  5-2.  Communication  Scheme 
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will  be  considered  in  the  subsequent  paragraphs  will  be  the  serial,  multiplexed 
MEL-STD-1553A  data  bus  and  associated  protocol.  This  is  the  implementation 
chosen  for  the  generic  bus  structure  of  Figure  4-1.  This  form  of  data  transfer 
incorporates  a loosely  coupled  interconnect  structure  and  is  referred  to  as  mes- 
sage passing,  as  opposed  to  tight  coupling,  which  is  characterized  by  shared, 
directly  accessible  memory  among  processors. 

A message  passing  implementation  was  chosen  over  the  tightly  coupled  imple- 
mentation because  it  more  nearly  optimizes  the  assessment  criteria,  as  explained 
below. 

a.  Flexibility.  Since  a message  passing  scheme  provides  a well-defined 
interface  between  processes,  the  effects  of  a change  in  the  process  can 
be  more  easily  ascertained  and  isolated  from  the  rest  of  the  system. 

This  means  essentially  that  any  suitable  algorithm  or  technique  can  be 
used  to  execute  the  function,  as  long  as  the  input  and  output  messages 
remain  the  same.  For  example,  this  allows  the  replacement  of  older 
technology  computers  with  newer,  low-cost  units  without  significantly 
impacting  upon  the  remainder  of  the  system. 

b.  Fault  Toler ance/Recoverv.  Message  passing  eases  the  task  of  fault 
isolation,  since  the  source  of  an  erroneous  message  is  known,  and  each 
message  is  checked  for  errors.  Faulty  units  can  automatically  be  iso- 
lated from  the  remainder  of  the  system,  because  of  the  possibilities 

to  refuse  messages  from  them  and  also  not  to  transmit  messages  to 
them.  These  possibilities  are  considerably  more  difficult  in  a shared- 
memory  environment.  In  general,  the  ability  to  accept  or  reject  data 
from  a selected  source  on  the  basis  of  either  the  message  content  or  a 
previous  message  from  a test  monitor  considerably  simplifies  the  data 
contamination  problem  and  makes  reconfiguration  easier. 

c.  Software  Considerations.  The  message  passing  protocol  establishes  a 
well-defined  interface  between  processes.  This  is  compatible  with 
modern  modular  and  HOL  programming  techniques  and  aids  in  the 
development  of  structured  software  which  can  be  tested  and  verified  at 
minimum  cost.  Shared  memory  environments  lead  to  software  inter- 
face problems,  especially  when  real-time  programming  is  involved. 

d.  Compatibility  with  Standards.  The  implementation  chosen  is  the  stan- 
dard (MIL -STD-1553)  serial  bus  and  appears  to  meet  the  data  transfer 
requirement  for  interprocessor  communications. 

5.6.1  Data  Transfer  Rates 

Figure  5-3  provides  a summary  of  data  transfers  required  for  the  current  S-3A 
operational  program.  The  circles  indicate  the  complement  of  DU's  associated 
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with  each  of  the  processor  groups  (1  through  8)  as  established  in  Table  5-1.  An 
additional  processor  group  (PG-9)  performs  the  system  health  monitoring  func- 
tion over  the  other  processor  groups,  acts  as  the  bus  controller,  and  controls 
reconfiguration  (if  it  is  not  itself  the  failed  unit.)  The  oblong  circles  indi- 
cate the  sensors/subsystems  and  their  relationship  to  the  processor  groups. 
Note  that  the  data  transfer  rates  are  normalized  to  hits  per  second  and,  there- 
fore, only  characterize  the  data  flow  on  a gross  basis.  The  self-loops  shown 
imply  intraprocessor  communications.  All  other  data  transfers  shown  are  con- 
sidered to  be  interprocessor  communications.  Since  the  data  transfers  include 
only  the  basic  information,  a data  transfer  analysis  should  also  take  into  account 
the  growth  and  overhead  factors  indicated  in  Figure  5-3. 

5.6.2  MIL-STD-1553A  Bus  Considerations 

The  1553A  data  bus  permits  a maximum  of  32  terminals  to  be  connected  on 
any  one  bus.  Information  is  transferred  on  a single  shielded,  twisted  pair  line 
at  a 1-megahertz  bit  rate.  Control  of  information  transmission  and  reception 
on  the  bus  resides  with  the  bus  controller,  which  initiates  all  transfers.  The 
data  bus  may  employ  three  modes  of  information  transfer: 

• Controller-to-  terminal 

• Terminal-to-controller 

• Terminal-to-terminal 

A terminal  is  considered  to  be  the  electronic  unit  necessary  to  interface  the 
bus  with  the  subsystem  and  the  subsystem  with  the  bus.  A redundant  bus  con- 
troller, when  not  functioning  as  a controller,  may  operate  as  a terminal.  Data 
are  transferred  serially  in  20-microsecond  frames,  each  divided  into  17  bit 
times  of  1 microsecond  and  one  3-microsecond  sync  interval.  All  messages 
are  addressed  by  use  of  three  types  of  words,  as  shown  in  Figure  5-4a: 

• Command  Word  — sent  by  bus  controller  to  the  appropriate  terminal; 
specifies  message  type;  and  sets  data  word  count  for  subsequent  trans- 
fer 

• Data  Word  — contains  16  bits  of  message  data,  sync  pattern,  and  a 
parity  bit 
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• Status  Word  — set  by  a terminal  in  response  to  a command  word;  iden- 
tifies terminal;  and  reports  status 

Message  formats  for  each  of  the  three  information  transfer  modes  are 
shown  in  Figure  5-4b.  Transfer  lime  implications  as  a function  of  data  words 
per  message  for  each  transfer  mode  are  shown  in  Figure  5-5  and  reflect  the 
formats  in  Figure  5-4.  Note  that  the  command  word  format  in  Figure  5-4 a con- 
sists of  a 5-bit  data  word  count;  therefore,  each  transfer  can  consist  of  a maxi- 
mum message  length  of  32  data  words.  Figure  5-4  shows  that  a considerable 
overhead  is  realized  for  messages  containing  six  or  fewer  data  words.  The 
actual  transfer  time  overhead  realized  for  a data  word  of  a particular  message 
length  can  be  computed  by  taking  the  difference  of  16  microseconds  and  the  cor- 
responding transfer  time  per  word  in  Figure  5-5.  It  can  be  observed  that  more 
efficient  bus  utilization  occurs  when  message  lengths  approach  32  data  words. 
This  is  further  demonstrated  in  Figure  5-6,  which  characterizes  bus  efficiency 
for  various  message  lengths. 

5.7  SYSTEM  CONFIGURATION  ANALYSIS 

In  developing  an  information  processing  system  architecture,  the  DU's  are 
mapped  into  processing  groups  called  nodes;  and  the  various  sensors,  subsys- 
tems, displays,  and  keysets  are  considered  to  be  peripherals.  These  nodes  and 
peripherals  are  assumed  to  be  loosely  coupled  where  data  transfers  are  per- 
formed via  1553  buses.  An  assessment  of  the  data  transfers  shown  in  Figure 
5-3  indicates  the  distributed  system  architecture,  shown  in  Figure  5-7,  which 
is  subsequently  substantiated  via  analyses.  For  reasons  discussed  later  (para- 
graph 5.  7.2),  the  functional  grouping  of  DU's  shown  in  Table  5-1  is  redefined 
to  reflect  the  functional  grouping  in  Table  5-2.  The  nodes  shown  in  Figure  5-7, 
therefore,  reflect  the  DU  grouping  indicated  in  Table  5-2. 

5.7.1  Data  Transfer  Analysis 

An  analysis  is  performed  based  on  the  data  transfer  requirements  shown 
in  Figure  5-2  and  the  system  configuration  shown  in  Figure  5-7.  As  Indicated 
previously,  only  interprocessor  data  transfers  are  considered,  that  is,  those 


5-14 


NADC- 79 161-40 

TABLE  5-2.  REVISED  DU  GROUPING 


PROCESSOR  GROUP 


ESM  Intercept  Maintenance 
ESM  Frequency  Control 
ESM  Classification 
ESM  Contact  Maintenance 


ADP  Mode  Control 
AOP  Data  Management 
ADP  Display  Control 
SRX  Frequency  Control 
ATR  Control 


ADP  Passive  Contact  Classification 
ADP  Passive  Contact  Maintenance 


ADP  Active  Ping  Control 
ADP  Active  Contact  Maintenance 


MAD  Display  Control 
MAD  Data  Management 
MAD  Signal  Feature  Recognition 
MAD  Contact  Maintenance 


RADAR  Display  Control 
RADAR  Data  Management 


Ballistics 

RADAR  Contact  Maintenance 


Display  Operator  Control 
Tactical  Display  Management 


Display  Refresh  Management 


Keyset  Control 


NAV  Position  Control 
NAV  Position  Calculation 
NAV  Data  .Management 
NAV  Track  Histo 
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data  transfers  performed  by  means  of  1553  buses.  This  implies  that  the  com- 
munication structure  among  nodes  and  peripherals  will  conform  to  the  protocol 
requirements  of  the  1553  bus.  The  1553  word  and  message  formats  to  be  em- 
ployed are  shown  in  Figu1-  5-5. 

5. 7. 1.1  Message  Formats 

For  purposes  of  analysis,  all  nodes  and  peripherals  are  considered  to  be 
remote  terminals,  with  the  exception  of  the  node  designated  as  the  controller 
(Node  90).  All  data  transfers  are  assumed  to  be  initiated  by  the  controller. 

When  a terminal  is  transmitting  a message,  that  terminal  is  considered  to  be 
the  source  of  the  transmission.  When  a terminal  is  receiving  a message,  that 
terminal  is  considered  to  be  the  destination.  Source  and  destination  terminals 
are  identified  by  means  of  terminal  addresses  that  are  specified  by  the  controller 
in  the  command  word.  Since  terminal  addresses  are  not  yet  determined  for  the 
terminals  (nodes  and  peripherals)  in  Figure  5-7,  the  numerical  assignments  shown 
can  be  considered  to  be  pseudo-addresses.  Other  information  contained  in  the 
command  word  includes  a data  word  count  which  permits  messages  of  variable 
length  to  be  transmitted  with  up  to  a maximum  of  32  16-bit  words.  In  addition, 
a transmit/receive  (T/R)  bit  indicates  whether  the  addressed  terminal  is  to 
transmit  or  receive  the  message. 

5. 7. 1.2  Message  Scheduling 

Messages  to  be  transmitted  are  scheduled  during  predetermined  periods 
called  cycles.  The  shortest  scheduling  period  is  called  a minor  cycle;  all  other 
cycles  are  an  integer  number  of  minor  cycles.  Figure  5-8  shows  scheduling 
periods  corresponding  to  various  cycles  in  which  a minor  cycle  is  defined  as  50 
milliseconds.  The  cycles  repeats  after  a time  period  equal  to  a major  cycle. 

The  number  of  minor  cycles  in  a major  cycle  is  some  power  of  2 (for  example, 

8,  16,  32).  Figure  5-8  provides  an  example  employing  this  message  scheduling 
scheme.  As  shown  therein,  six  subaddresses  are  employed  to  perform  the  re- 
quired transfer  for  the  example. 
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5. 7. 1.3  Message  Structure 

In  order  for  the  S-3A  information  flow  requirements  to  adapt  to  the  system 
configuration  of  Figure  5-7,  messages  are  constructed  to  perform  the  1553  bus 
data  transfers.  In  constructing  these  messages,  flexibility  objectives  were  con- 
sidered in  terms  of  minimizing  both  bus  utilization  and  subaddresses  so  that 
future  growth  could  be  accommodated.  The  results  of  an  analysis  indicate  that 
a minor  cycle  of  50  milliseconds  is  required  to  realize  the  required  data  trans- 
fers. A complete  list  of  messages  required  for  the  system  configuration  of 
Figure  5-7  is  shown  in  Table  5-3  and  reflects  data  transfer  rates  as  determined 
from  References  2 and  3.  As  indicated  previously,  the  source  and  destination 
terminal  assignments  are  pseudo-addresses  which  can  be  reassigned  prior  to 
implementation  in  the  BASIC  laboratory.  However,  command  words  can  be  con- 
structed by  employing  the  word  counts,  transmitter  subaddresses,  and  receiver 
subaddresses  directly  from  Table  5-3.  Note  that  the  command  word  for  the 
transmitter  would  have  the  T/R  bit  set  to  1,  and  the  receiver  would  have  the 
T/R  bit  set  to  0.  Scheduling  information  can  also  be  obtained  directly  from  the 
cycle  field  indicated.  The  maximum  cycle  required  is  4,  which  corresponds  to 
300  milliseconds,  as  shown  in  Figure  5-8.  Asynchronous  messages  in  Table  5-3 
correspond  to  those  messages  with  a 0 entry  in  the  period  field  and  no  entry  in 
the  cycle  field.  In  the  case  of  asynchronous  messages,  both  the  transmitter  and 
receiver  subaddresses  are  assigned  a value  of  30  for  compatibility  with  either 
the  1553A  or  1553B  bus.  Other  information  provided  in  Table  5-3  includes  the 
identification  of  the  bus  (corresponding  to  Figure  5-7)  used  for  each  message 
transfer.  Provisions  are  also  made  for  monitoring  the  health  of  the  individual 
modes  by  means  of  the  controller/monitor  node  (90).  This  is  accomplished  by 
requiring  each  node  to  issue  a message  to  be  received  and  evaluated  by  the  moni- 
tor every  minor  cycle  (50  milliseconds). 
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TABLE  5-3.  MESSAGE  STRUCTURE  (Sheet  1 of  3) 


F 

SRC 

XMT 

OST 

WORDS 

PERIOD 

BUS 

CYC 

WRO 

RCV 

TIME 

NOE 

SUB 

NOE 

PER  SEC 

IN 

10 

CODE 

CNT 

SUB 

IN 

AOR 

MSEC 

AOR 

H SEC 

*** 

• 

10 

1 

70 

840 

509 

1 

0 

32 

1 

725 

• 

10 

2 

82 

100 

450 

1 

2 

23 

1 

546 

• 

10 

3 

82 

800 

450 

1 

0 

30 

2 

685 

• 

10 

4 

82 

450 

1000 

1 

1 

30 

3 

685 

• 

5 

1 

16 

4 

405 

• 

10 

6 

111 

100 

1000 

1 

2 

20 

1 

485 

« 

10 

7 

118 

240 

1000 

1 

1 

24 

1 

565 

• 

10 

20 

90 

180 

50 

1 

0 

8 

1 

245 

• 

10 

30 

70 

18 

0 

1 

3 

30 

145 

• 

10 

30 

82 

30 

0 

1 

3 

30 

145 

* 

10 

30 

118 

6 

0 

1 

3 

30 

145 

1' 

• 

21 

1 

10 

10 

1000 

1 

4 

10 

1 

285 

• 

21 

2 

70 

3000 

2000 

3 

0 

32 

2 

725 

• 

3 

0 

32 

3 

725 

• 

4 

0 

32 

4 

72*! 

• 

5 

0 

32 

5 

725 

• 

6 

1 

32 

6 

725 

• 

7 

2 

16 

7 

405 

I 

* 

21 

8 

117 

150 

1000 

1 

2 

30 

1 

685 

• 

21 

29 

90 

ISO 

so 

1 

0 

8 

2 

245 

m 

• 

21 

30 

32 

6 

0 

1 

3 

30 

145 

1 

* 

22 

105 

3 

0 

1 

• 

22 

1 

10 

150 

1500 

1 

2 

30 

2 

685 

* 

22 

2 

82 

50 

50 

1 

0 

3 

5 

145 

• 

22 

3 

105 

60 

1000 

1 

3 

30 

1 

685 

# 

22 

29 

90 

160 

50 

1 

0 

8 

3 

245 

* 

22 

30 

10 

3 

0 

1 

3 

30 

145 

• 

22 

30 

105 

3 

0 

1 

3 

30 

145 

• 

30 

1 

82 

400 

40 

1 

0 

20 

6 

485 

• 

30 

2 

82 

3600 

160 

1 

0 

32 

7 

725 

♦ 

3 

0 

32 

8 

725 

* 

4 

0 

32 

9 

725 

• 

5 

0 

32 

10 

725 

• 

6 

0 

32 

11 

725 

• 

7 

0 

32 

12 

725 

• 

30 

29 

90 

160 

50 

1 

0 

8 

4 

245 

• 

30 

30 

40 

3 

0 

1 

3 

30 

145 

• 

30 

30 

70 

3 

0 

1 

3 

30 

145 

• 

30 

30 

82 

3 

0 

1 

3 

30 

145 

• 

30 

30 

115 

3 

0 

1 

3 

30 

145 

• 

40 

1 

50 

300 

100 

1 

1 

30 

1 

685 

• 

40 

2 

82 

530 

1000 

1 

1 

32 

13 

725 

• 

3 

1 

21 

14 

505 

• 

40 

4 

100 

900 

100 

4 

0 

30 

1 

685 

• 

5 

4 

30 

2 

685 

• 

40 

6 

119 

10 

1000 

4 

4 

10 

1 

285 

• 

40 

7 

122 

10 

1000 

4 

4 

10 

1 

285 

• 

40 

8 

70 

10 

1000 

1 

4 

10 

5 

285 

• 

40 

9 

82 

10 

1000 

1 

4 

10 

15 

285 

• 

40 

29 

90 

180 

50 

1 

J 

8 

5 

245 

• 

40 

30 

10 

3 

0 

1 

3 

30 

145 

• 

40 

30 

82 

3 

0 

1 

3 

30 

145 

• 

50 

1 

40 

100 

100 

1 

1 

10 

1 

285 

• 

50 

2 

70 

800 

2000 

1 

0 

32 

3 

725 
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TABLE  5-3.  MESSAGE  STRUCTURE  (Sheet  2 of  3) 


SRC 

XMT 

DST 

WORDS 

PERIOD 

BUS 

CYC 

WRO 

RCV 

TIME 

NDE 

SUB 

NDE 

PER  SEC 

IN 

ID 

CODE 

CNT 

SUB 

IN 

ADR 

MSEC 

ADR 

M SEC 

3 

2 

32 

4 

725 

50 

29 

90 

160 

50 

1 

0 

8 

6 

245 

SO 

30 

40 

3 

0 

1 

1 

3 

30 

145 

50 

30 

82 

3 

0 

1 

3 

30 

145 

60 

30 

50 

0 

1 

3 

30 

145 

70 

1 

10 

300 

50 

1 

0 

15 

3 

385 

70 

2 

10 

420 

50 

1 

0 

21 

6 

505 

70 

3 

21 

210 

100 

1 

1 

21 

1 

505 

70 

4 

21 

960 

1000 

1 

0 

32 

23 

725 

70 

5 

22 

210 

100 

1 

1 

21 

1 

505 

70 

6 

30 

300 

50 

1 

0 

15 

1 

385 

70 

7 

30 

420 

50 

1 

0 

21 

2 

505 

70 

8 

40 

105 

200 

1 

2 

21 

2 

505 

70 

9 

50 

105 

200 

1 

2 

21 

2 

505 

70 

10 

82 

1240 

50 

5 

0 

19 

16 

465 

11 

0 

21 

17 

505 

12 

0 

21 

16 

505 

70 

13 

82 

1500 

2000 

5 

0 

30 

19 

685 

14 

0 

30 

20 

685 

15 

0 

30 

21 

685 

70 

16 

82 

320 

1000 

5 

1 

32 

22 

725 

70 

17 

82 

100 

2000 

5 

2 

11 

23 

305 

70 

29 

90 

160 

50 

1 

0 

8 

5 

245 

70 

30 

10 

13 

0 

1 

13 

30 

345 

70 

30 

10 

63 

0 

1 

21 

30 

505 

70 

30 

82 

16 

0 

5 

IE 

30 

405 

81 

101 

12000 

25 

2 

81 

102 

36000 

25 

2 

81 

103 

40000 

25 

2 

81 

104 

40000 

25 

2 

81 

29 

90 

160 

50 

4 

1 

0 

8 

8 

245 

82 

1 

10 

240 

50 

1 

0 

12 

1 

325 

82 

2 

22 

20 

50 

1 

0 

1 

2 

105 

82 

3 

40 

40 

50 

1 

0 

2 

3 

125 

82 

5 

81 

4000 

500 

1 

0 

32 

1 

725 

6 

0 

32 

2 

725 

7 

0 

32 

3 

725 

8 

0 

32 

4 

725 

9 

0 

32 

5 

725 

10 

0 

32 

6 

725 

11 

1 

16 

7 

405 

82 

12 

108 

8 

1000 

1 

4 

8 

1 

245 

82 

29 

90 

160 

50 

1 

0 

8 

9 

245 

82 

30 

10 

48 

0 

1 

3 

30 

145 

62 

30 

21 

6 

0 

1 

3 

30 

145 

82 

30 

22 

3 

0 

1 

3 

30 

145 

82 

30 

30 

3 

0 

1 

3 

30 

145 

82 

30 

40 

9 

0 

1 

3 

30 

145 

82 

30 

40 

6 

0 

1 

3 

30 

145 

82 

30 

50 

3 

0 

1 

3 

30 

145 

82 

30 

70 

25 

0 

1 

5 

30 

185 

82 

30 

70 

14 

0 

1 

4 

14 

30 

365 

90 

1 

21 

160 

50 

1 

0 

8 

29 

245 

90 

2 

30 

160 

SO 

1 

0 

8 

29 

245 
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TABLE  5-3.  MESSAGE  STRUCTURE  (Sheet  3 of  3) 


SRC 

XMT 

OST 

WORDS 

PERIOD 

BUS 

CYC 

WRO 

RCV 

TIME 

NOE 

SUB 

NOE 

PER  SEC 

IN 

10 

CODE 

CNT 

SUB 

IN 

ADR 

MSEC 

ADR 

H SEC 

90 

30 

21 

0 

1 

7 

30 

225 

100 

9 

40 

900 

100 

4 

0 

32 

4 

726 

9 

1 

26 

5 

605 

105 

14 

22 

60 

SO 

1 

0 

3 

3 

14E 

100 

15 

70 

240 

50 

3 

0 

12 

8 

325 

107 

16 

70 

120 

200 

3 

2 

24 

9 

565 

108 

17 

82 

8 

1000 

1 

4 

8 

24 

245 

110 

19 

70 

10 

200 

3 

2 

2 

10 

125 

111 

20 

10 

100 

250 

1 

2 

25 

5 

585 

112 

21 

70 

20 

200 

3 

2 

4 

11 

165 

113 

22 

70 

60 

200 

3 

2 

12 

12 

325 

114 

23 

70 

180 

50 

3 

0 

8 

13 

245 

115 

24 

30 

48 

so 

1 

0 

3 

2 

145 

117 

26 

21 

150 

0 

1 

3 

30 

145 

123 

1 

82 

3 

0 

5 

3 

30 

145 

124 

1 

82 

40 

0 

5 

20 

30 

485 

125 

1 

82 

40 

0 

5 

20 

30 

485 

126 

1 

82 

40 

0 

5 

20 

30 

485 

5.7. 1.4  Bus  Utilisation 

The  bus  utilization/transfer  times  shown  for  each  message  in  Table  5-3  are 
a function  of  word  length  and  correspond  to  the  terminal-to-terminal  transfers 
characterized  in  Figure  5-5.  In  addition,  since  a gap  time  of  2 to  5 microseconds 
occurs  for  each  message  transfer,  5 microseconds  are  included  with  each  mes- 
sage transfer  time  to  reflect  a worst-case  situation.  As  can  be  observed  from 
Figure  5-8,  a bus  is  not  uniformly  loaded  over  an  entire  scheduling  interval  of 
S00  milliseconds;  that  is,  a scheduling  interval  consists  of  the  16  50-microsecond 
scheduling  periods  PI  through  P16,  after  which  the  500-millisecond  interval  re- 
peats. A maximum  or  peak  bus  loading  occurs  when  all  cycles  (0  through  4)  are 
coincident  as  depicted  for  scheduling  period  PI  in  Figure  5-8.  Figure  5-9  char- 
acterizes utilization  of  the  various  1553  bus  structures  shown  in  Figure  5-7  with 
respect  to  transfer  groups  as  defined  therein.  A summary  of  bus  utilization  for 
the  peak  loading  period  PI  and  the  weighted  average  for  an  800-millisecond  inter- 
val is  given  in  Table  5-4. 
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TABLE  5-4.  PEAK/AVERAGE  BUS  UTILIZATION 


BUS  ID 

UTILIZATION  (%) 



PEAK 

WEIGHTED  AVERAGE 

1 

64 

47 

3 

12 

9 

4 

7 

4 

5 

9 

8 

5.7.2  Processing  Analysis 
5.7.2. 1 Introduction 

Figure  5-7  represents  the  recommended  full-up  processing  system  configura- 
tion for  the  BASIC  laboratory.  It  may  be  classified  as  a homogeneous  hierarchical 
system,  since  it  uses  standard  computers  interconnected  via  a hierarchy  of  buses. 
The  system  is  derived  (via  the  information  handling  methodology  described  in 
Section  2 of  this  report)  from  the  processing  requirements  of  the  S-3A  aircraft. 

The  primary  requirements  for  BASIC  application  are  its  ability  to  meet  the  per- 
formance requirements,  availability  in  the  event  of  processor  failure,  expandability 
to  accommodate  new  or  changing  requirements,  and  compatibility  with  hardware 
and  software  standards. 

Toward  these  objectives,  the  system  is  oriented  around  a redundant  set  of 
buses  used  for  subsystem-to-subsystem  communication,  with  separate  secondary 
buses  used  for  computer/peripheral  communications.  Peripheral  interfaces  with 
a secondary  bus  are  implemented  using  identical  redundant  microprocessors, 
which,  in  a platform  application,  are  projected  to  be  implemented  on  a single 
board.  For  the  BASIC  application,  however,  these  microprocessors  are  more 
powerful,  flexible  devices  which  can  simulate  nonavailable  peripherals  and  sub- 
systems. These  microcomputers  are  redundant,  and  are  controlled  by  the  mini- 
computers attached  to  their  particular  secondary  buses  (see  Figure  5-10).  Thus, 
the  interfaces  can  be  made  standard  and  identical,  enabling  easier  reconfiguration 
and  expansion. 


Figure  5-10.  Secondary  Bus  Interfaces 

Availability  is  provided  by  redundant  hardware,  redundant  data  paths,  and 
reconfiguration  software  stored  in  the  minicomputers  and  in  a bulk  storage  medium 

I . accessible  to  all  the  processors.  Additionally,  one  computer  is  dedicated  to  the 

test/monitor  function  and  can  be  used  as  a spare  in  case  of  a processor  failure. 

r 

The  recommended  architecture  represents  a system  in  which  cost,  flexi- 
bility, and  availability  are  considered  more  important  than  weight  and  processor 
speed.  Future  requirements  may  be  accommodated  through  the  use  of  additional 
computers  rather  than  through  the  use  of  excess  processing  capability  within  the 
existing  computers.  This  approach  reduces  the  cost  of  programming,  since 
interaction  between  modules,  especially  for  the  purpose  of  increasing  real-time 
speed  of  response,  is  minimized.  This  approach  is  also  cost-effective  for  a 

l n 

m 
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demonstration  laboratory,  because  a demonstrated  and  validated  processing 
system  concept  may  be  weight-optimized  for  a particular  application  when  the 
physical  constraints  and  unique  processing  requirements  of  that  application  are 
well  defined. 

The  following  sections  will  present  the  components  recommended  for  use  in 
the  BASIC  laboratory  and  the  rationale  for  their  selection,  the  software  structure, 
the  interface  definition,  the  control  structure,  and  some  reconfiguration  con- 
siderations. 

5. 7. 2. 2 Component  Selection 

5.7. 2.2. 1 Nodes  (Minicomputers).  The  performance  requirements  for  the  S-3A 
operational  program  were  used  as  a baseline  for  the  selection  of  computers  for 
the  nodes.  These  performance  requirements,  in  terms  of  memory  size  and 
throughput,  are  presented  in  Table  5-5.  The  figures  shown  are  oased  on  the  AN/ 
AYK-10  multiprocessor,  which  uses  32-bit  memory  words  and  has  two  central 
processing  units.  These  programs  represent  almost  all  of  the  processing  per- 
formed by  the  AN/AYK-10.  The  processing  time  for  the  executive  is  included  in 
other  portions  of  the  operational  program  (and  has  proved  impossible  to  accurately 
separate).  The  functional  description  of  the  subprograms  listed  in  Table  5-4 
can  be  found  in  paragraph  3. 1. 2 of  this  report. 

Table  5-6  presents  the  estimated  requirements  for  the  various  nodes  based 
on  the  operational  requirements  of  Table  5-5  plus  considerations  of  availability 
and  compatibility  with  ongoing  technology  programs.  The  figures  in  Table  5-6 
are  based  on  a 16-bit  minicomputer,  since  the  standard  AN/AYK-14  would  be 
more  than  adequate  to  meet  the  processing  requirements.  The  configurations 
recommended  are  AN/AYK-14  minicomputers.  Before  the  BASIC  architecture 
is  fully  Implemented,  newer  versions  of  the  standard  minicomputer  will  probably 
be  available.  The  recommended  configurations  will  be  regarded,  therefore,  as 
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TABLE  5-5.  SUBPROGRAM  SYSTEM  RESOURCE  REQUIREMENTS 


SUBPROGRAM 

NUMBER  OF 
INSTRUCTION 
WORDS 

NUMBER  OF 
LOCAL  DATA 
WORDS 

NUMBER  OF 
DYNAMIC  DATA 
WORDS 

KEYPAC,  DISPAC 

16, 800 

5,000 

350 

NAV,  STEER,  and 
SLTA 

8,400 

1,200 

500 

COMM 

21, 100 

1,200 

160 

ARMCON,  SESCON, 
and  Ballistics 

6,000 

400 

100 

ACC  ON,  PACK,  and 
ACTIVE 

34, 200 

7,200 

1,700 

FLIR 

1,600 

200 

50 

RADAR 

3,300 

300 

130 

MAD 

2,200 

3,300 

50 

ESM 

1,700 

1,400 

120 

TABLE  5-6.  PROCESSING  NODE  SIZING  ESTIMATES  FOR  BASIC  ARCHITECTURE 


NODE 

ESTIMATED 
NUMBER  OF 
INSTRUCTIONS 

ESTIMATED 
NUMBER  OF 
DATA  WORDS 

- ■—  '■  " ■ ■ i 

ESTIMATED 

THROUGHPUT 

(OPERATIONS 

PER  SEC) 

10  - ESM,  FLIR, 
ARMCON, 
SESCON 

14,000 

4,000 

175K 

21  - COMM 

31,650 

2,750 

75K 

22  - RADAR 

5,000 

860 

30K 

30  - MAD 

3,300 

7,600 

225K 

40  - ACC  ON,  ADP, 
ACTIVE,  SRX, 
ATR  CTRL 

20,000 

10,000 

290K 

50  - Passive  Contact 
Maintenance, 
Classification 

14,000 

8,000 

206K 

70  - NAV,  Tactical 

12,600 

3,400 

180K 

81/82-  Display 

36,000 

60,000 

400K 
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representing  capability  rather  than  as  unique  hardware  devices.  The  recom- 
mended configurations  for  each  node  are  described  below. 

Node  10 

The  Node  10  processor  performs  the  search  stores  control,  armament  con- 
trol, FLIR,  and  ESM  functions  of  the  S-3A.  This  node  has  modest  memory, 
speed,  and  I/O  requirements.  Since  loading  will  not  be  excessive,  Node  10  could 
act  as  a backup  processor  for  either  Node  30  or  the  reconfiguration  monitor. 

The  number  of  ESM  signals  processed  could  be  increased  from  16  to  32  with 
slight  additional  bus  loading.  A 32K-word  memory  module  would  be  adequate  for 
the  operational  requirements.  The  recommended  configuration,  however,  con- 
tains facilities  for  two  64K  modules,  so  that  Node  10  can  act  as  a backup  for  the 
reconfiguration  monitor,  the  MAD  processor,  or  both  if  necessary. 

The  I/O  requirements  are  such  that  the  primary  bus  is  not  unduly  loaded  by 
the  approximately  200  words  per  second,  transmitted  between  the  ESM  subsystem 
and  Node  1.  Since  a single  connection  to  the  primary  bus  has  obvious  advantages 
in  terms  of  communication  and  reconfigurability,  tins  option  was  chosen. 

An  IOP  option  was  not  considered  necessary  for  the  operational  requirements, 
but  the  role  of  backup  for  the  reconfiguration  monitor  requires  it.  An  extended 
arithmetic  unit  (EAU)  would  be  desirable  since  ESM  processing  requires  many 
arithmetic  operations,  and  floating-point  arithmetic  is  more  compatible  with 
high-level  language  programming  than  fixed-point  arithmetic.  The  EAU  is  not 
strictly  necessary  for  proper  operation,  but  the  recommended  configuration 
should  be  able  to  accept  an  EAU  if  desired.  For  maximum  flexibility,  therefore, 
an  XN-1  configuration  chassis  is  recommended.  A discrete  interface  module 
(DIM)  is  required  for  control  of  the  processor  from  external  sources.  A summary 
of  the  recommended  configuration  is  given  in  Table  5-7. 
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TABLE  5-7.  NODE  10  CONFIGURATION 


CHASSIS  - XN-1 

MODULE 

DESIGNATION 

QUANTITY 

Power  Supply 

PCM-2 

(1) 

Memory 

32K  word 

(1) 

Memory  Control 

MCM 

(1) 

General  Processor 

GPM 

(1) 

Serial  Interface 

SIM 

(1) 

Discrete  Interface 

DIM 

(1) 

I/O  Processor 

IOP 

(1) 

Nodes  21  and  22 

Nodes  21  and  22  are  represented  to  be  two  computers  for  several  reasons. 

a.  The  requirements  of  the  radar  and  communication  subsystems  are  such 
that  subsystem-unique  processing  will  probably  also  occur  in  that  node 
(that  is,  the  Transmission  and  Information  Exchange  System  (TIES)  com- 
munication processing  uses  the  AN/AYK-14  as  a subsystem  processor). 
This  will  require  processing  capability  in  excess  of  the  S-3A  requirements 
to  accommodate  this  subsystem-unique  processing. 

b.  With  separate  nodes,  the  programming  may  be  done  independently  with 
minimized  interaction  between  the  processes. 

c.  With  two  physical  nodes,  the  computers  can  act  as  backups  for  each 
other  and  for  Node  70  in  case  of  failure. 

Notwithstanding  the  above  discussions,  implementing  these  two  nodes  in  one 
AN/AYK-14  was  considered  cost-effective  for  the  BASIC  application.  However, 
to  retain  the  functional  separation  required  above,  the  AN/AYK-14  for  Nodes  21 
and  22  should  be  assigned  two  terminal  addresses;  the  memory  used  by  the  com- 
munications and  radar  functions  should  be  distinct;  and  all  I/O’s  between  the 
communications  and  radar  functions  should  be  conducted  over  the  primary  bus. 

This  will  allow  future  separation  of  the  node  into  two  computers  with  minimum 
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The  processing  requirements  for  Nodes  21  and  22  are  such  that  an  XN-2 
configuration  could  be  used.  Three  32K  memory  modules  or  two  64K  memory 
modules  would  satisfy  the  storage  requirements  and  allow  reconfiguration  in 
case  of  failure.  I/O  requirements  are  modest,  approximately  4000  words  per 
second,  indicating  that  this  node  need  not  contain  an  IOP.  Since  the  processing 
for  this  node  is  primarily  a management  function  and  few  extensive  arithmetic 
operations  are  performed,  an  EAU  was  not  considered  necessary.  Although  an 
XN-2  chassis  type  could  be  used,  an  XN-1  is  recommended  because  of  its  greater 
flexibility  and  expandability.  A DEM  is  also  necessary  for  external  control.  A 
summary  of  the  recommended  configuration  of  Nodes  21  and  22  is  presented  in 
Table  5-8. 

Node  30 

The  MAD  processing  requirements  for  the  S-3A  can  be  reasonably  well  ac- 
commodated by  an  AN/AYK-14,  XN-1  configuration  using  an  EAU.  As  in  the 
case  of  Node  1,  an  EAU  is  not  strictly  necessary,  but  programming  complexity 


TABLE  5-8.  CONFIGURATION  FOR  NODES  21  AND  22 


CHASSIS  - XN-1 

L 

MODULE 

DESIGNATION 

QUANTITY 

Power  Supply 

PCM-2 

(1) 

Memory 

32  K word 

(3) 

or 

64K  word 

(2) 

Memory  Control 

MCM 

(1) 

General  Processor 

GPM 

(1) 

Serial  Interface 

SIM 

(4) 

Discrete  Interface 

DIM 

(1) 
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is  significantly  decreased  if  floating-point  arithmetic  can  be  used;  and  the  speed 
requirements  are  such  that  the  microprogrammed  floating-point  capability  might 
not  be  fast  enough  for  the  application.  Floating-point  instructions  in  the  AN/AYK-14 
run  at  a 180 K operations  per  second  rate.  The  overall  speed  required  for  the 
MAD  application  is  220K  operations  per  second.  This  speed  requirement  could 
probably  be  met,  since  the  program  does  not  contain  only  floating-point  calcu- 
lations; but  careful  programming  would  be  required,  and  growth  would  be  pro- 
hibited. 

Memory  requirements  are  small,  and  a single  32 K memory  module  will 
more  than  suffice.  An  IOP  is  not  considered  necessary  for  this  node  since  the 
I/O  requirements  are  small.  A summary  of  the  recommended  configuration  is 
presented  in  Table  5-9. 

Node  40  — Acoustic  Data  Processing 

The  processing  requirements  for  Node  40  are  somewhat  difficult  to  assess 
since  this  node  performs  many  different  functions  on  a demand  basis  as  required 
by  the  sensor  operator  (SENSO).  Node  40  has  one  major  periodic  function,  which 
is  the  input  of  acoustic  data  (12  milliseconds  of  processing  time  every  100  milli- 
seconds). Other  tasks  are  in  response  to  operator  commands  or  to  sonobuoy 

TABLE  5-9.  NODE  30  CONFIGURATION 


CHASSIS  — XN-1 

MODULE 

DESIGNATION 

QUANTITY 

Power  Supply 

PCM-2 

(1) 

Memory 

32K  word 

(1) 

Memory  Control 

MCM 

(1) 

Serial  Interface 

SIM 

(1) 

Extended  Arithmetic  Unit 

EAU 

(1) 

Discrete  Interface 

DIM 

(1) 
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signals.  Although  these  other  tasks  occur  infrequently,  they  are  randomly 
spaced  in  time  and  can  thus  cause  heavy  peak  loading.  The  processing  capa- 
bility must  therefore  be  adequate  to  ensure  proper  response  time  under  high- 
load  conditions,  even  though  the  average  instruction  processing  rate  is  very 
low.  An  AN/AYK-14,  XN-2  configuration  is  adequate  for  this  node.  Two  32K 
memory  modules  will  be  necessary,  since  a large  number  of  program  tasks 
must  be  stored.  Neither  an  IOP  nor  an  EAU  is  considered  necessary  for  this 
application.  A summary  of  the  recommended  configuration  for  Node  40  is  given 
in  Table  5-10. 

Node  50  — Passive  Contact  Maintenance,  Classification 

The  requirements  for  Node  50  are  similar  to  those  for  Node  40,  and  the 
same  types  of  functions  are  performed.  One  major  periodic  function  processes 
passive  buoys  and  requires  about  3 seconds  of  processing  time  every  15  seconds 
(worst  case).  Other  operator  demand  tasks  are  also  performed  in  this  mode. 
Nodes  40  and  50  represent  a processing  throughput  requirement  in  excess  of  that 


TABLE  5-10.  NODES  40  AND  50  CONFIGURATION 


CHASSIS  - XN-2 

MODULE 

DESIGNATION 

” —————— n 

QUANTITY 

Power  Supply 

PCM-1 

(1) 

Memory 

32 K word 

(2) 

or 

64 K word 

(1) 

Memory  Control 

MCM 

(1) 

General  Processor 

GPM 

(1) 

Serial  Interface 

SIM 

(2) 

Discrete  Interface 

DIM 

(1) 
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attainable  by  a single  AN/AYK-14.  For  this  reason  and  for  redundancy  consider- 
ations, two  nodes  are  necessary.  The  configuration  recommended  for  Node  50 
is  identical  to  that  recommended  for  Node  40  and  is  summarized  in  Table  5-10. 

Node  70  — Navigation  and  Tactical  Processing 

Node  70  was  chosen  as  an  AN/AYK-14,  XN-2  configuration  since  the  proces- 
sing and  memory  requirements  can  easily  be  met  and  since  this  computer  is 
planned  for  the  Integrated  Inertial  Sensor  Assembly /Global  Positioning  System 
(DSA/ GPS)-based  navigation  subsystem,  which  is  scheduled  to  be  demonstrated 
in  the  BASIC  laboratory  in  the  near  future.  This  system  will  probably  have  more 
stringent  computational  requirements  than  the  S-3A  implementation,  since  it 
will  be  used  for  many  platforms.  Therefore,  considerable  excess  processing 
capability  over  the  S-3A  requirements  is  necessary.  The  AN/AYK-14  will  pro- 
vide this  capability.  The  data  update  rate  between  Node  70  and  the  display  sub- 
system may  require  a 16-millisecond  minor  cycle,  rather  than  the  current  50 
milliseconds.  Since  the  display  subsystem  as  proposed  by  the  Advanced  Integrated 
Display  System  (AIDS)  will  have  a secondary  bus  between  the  integrated  control 
panels  and  the  display  processors,  it  was  considei'ed  convenient  to  interface  Node 
70  to  this  secondary  bus  as  well  as  to  the  system  bus.  The  secondary  bus  could 
have  the  required  16-millisecond  minor  cycle.  This  interconnection  also  pro- 
vides for  the  possibility  that  Node  70  could  act  as  a partial  backup  in  case  of 
Node  31  or  82  failures,  and  conversely.  An  XN-2  configuration  can  fulfill  the 
requirements,  with  a single  32K-word  module  and  three  serial  interface  module 
tSIM)  channels.  At  this  point,  the  microprogrammed  floating-point  capability 
of  the  XN-2  appears  to  be  sufficient  for  the  navigation  requirements,  so  an  EAU 
is  probably  not  necessary.  An  IOP  will  not  be  necessary  because  of  the  rela- 
tively low  I/O  rate  for  Node  70.  A summary  of  the  recommended  configuration 
appears  in  Table  5-11. 
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TABLE  5-11.  NODE  70  CONFIGURATION 


CHASSIS  — XN-2 

MODULE 

DESIGNATION 

QUANTITY 

Power  Supply 

PCM  = 1 

(1) 

Memory 

32 K word 

(1) 

Memory  Control 

MCM 

(1) 

General  Processor 

GPM 

(1) 

Serial  Interface 

SIM 

(3) 

Discrete  Interface 

DIM 

(1) 

Nodes  81  and  82  — Display 


The  configuration  for  Nodes  81  and  82  is  identical  and  in  conformance  with 
the  planned  comiguration  of  the  AIDS  program,  which  is  scheduled  to  be  demon- 
strated by  the  BASIC  laboratory.  The  display  subsystem  shown  in  the  system 
configuration  represents  the  AIDS  hardware  configuration;  therefore,  the  recom- 
mended configuration,  summarized  in  Table  5-12,  reflects  the  computers  speci- 
fied in  the  preliminary  AIDS  system  specification  (Reference  18). 


TABLE  5-12.  NODES  SI  and  S2  CONFIGURATION 


CHASSIS  - XN-1 

MODULE 

DESIGNATION 

QUANTITY 

Power  Supply 

PCM- 2 

(1) 

Memory 

64K  word 

(1) 

32K  word 

(1) 

Memory  Control 

MCM 

(1) 

General  Processor 

GPM 

(1) 

Extended  Arithmetic 

EAU 

(1) 

Serial  Interface 

SEM 

(2) 

Bus  Extender 

BEM 

(1) 

Discrete  Interface 

DIM 

(1) 
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Node  90  — Bus  Control/Reconfiguration  Monitor 

The  functions  of  this  node  are  to  monitor  all  other  nodes  and  to  control  re- 
configuration if  another  node  fails.  Node  90  will  act  as  a bus  controller  in  ac- 
cordance with  MIL-STD-1553,  and  it  will  act  as  a backup  processor  for  Nodes 
10  and  30.  Accordingly,  it  needs  extensive  capability  for  its  backup  role.  The 
recommended  configuration  is  presented  in  Table  5-13. 

The  recommended  configurations  for  each  node  are  summarized  in  Table 
5-14. 

5. 7. 2. 2. 2 Microcomputer  Components.  The  microcomputers  described  in  the 
introduction  serve  primarily  as  interfaces  between  subsystem  sensors  or  sub- 
system processors  and  the  standard  serial  bus.  Several  designs  for  a single- 
board module  for  this  purpose  exist  and  are  being  implemented.  However,  for 
the  BASIC  application  these  devices  must  have  considerable  flexibility,  since  in 
most  cases  the  devices/subsystems  to  which  they  connect  will  not  be  the  real 
devices  but  some  land  of  simulator.  In  addition,  the  interface  microcomputers 
may  be  required  to  respond  to  multiple  addresses,  as  in  the  case  of  one 


TABLE  5-13.  NODE  90  CONFIGURATION 


CHASSIS  - XN-1 

MODULE 

DESIGNATION 

QUANTITY 

Power  Supply 

PCM-2 

(1) 

Memory 

32K  word 

(2) 

Memory  Control 

MCM 

(1) 

General  Processor 

GPM 

(1) 

I/O  Processor 

IOP 

(1) 

Serial  Interface 

SIM 

(1) 

Discrete  Interface 

DIM 

(1) 

Extended  Arithmetic 

EAU 

(1) 

5-37 
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OPTIONAL  IN  LIEU  OF  32K  WORD  MODULE(S) 
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simulator  representing  multiple  sensors,  such  as  in  the  navigation  area.  For 
these  reasons,  it  is  recommended  that  one  of  the  more  powerful  microcomputer 
chip  sets  be  used  to  implement  the  interface  microcomputers  for  the  BASIC 
laboratory.  One  such  microcomputer  interface  has  already  been  implemented 
using  the  Z-2  chip  set.  This  implementation  appears  adequate  for  the  projected 
simulation  needs  of  BASIC  and  is  therefore  recommended.  A list  of  Z-2  micro- 
computer interface/simulator  configuration  hardware  is  summarized  in  Table 
5-15.  A detailed  description  of  the  manner  in  which  1553  bus  data  transfers  are 
performed  with  the  Z-2  and  interface  module  (IM)  is  contained  in  Reference  17. 

5.7. 2.  2.  3 Bus  Selection.  Two  MIL-STD-1553  buses  were  selected  primarily 
because  they  both  meet  the  requirements  and  are  designated  standard.  Further- 
more, advanced  bus  technology  and  concepts  are  likely  to  start  with  the  1553  as 
a baseline,  thus  allowing  BASIC  to  more  easily  grow  into  advanced  technolog}’ 
bus  configurations,  such  as  a higher  speed  fiber-optic  version  of  1553. 

The  primary  purposes  of  the  redundant  buses  (Bus  Numbers  2,  3,  4,  5)  are 
to  minimize  the  impact  of  subsystem  configuration  changes  on  the  main  bus  and 
to  provide  alternate  paths  from  a computer  to  a peripheral,  so  that  a computer 
failure  will  not  result  in  the  isolation  of  its  peripheral  from  the  remainder  of  the 
system. 

TABLE  5-15.  MICROCOMPUTER  SIMULATOR  CONFIGURATION 


MODULE 

QUANTITY 

Z80-CPU  card  - 4 MHz 

(1) 

16  K PROM  card 

(1) 

TU-ART  I/O  interface  card 

(1)  per  subsystem 

16K  RAM  card-250  nsec  access  time 

(2)  simulated 

1553  bus  IM  card  set 

(1) 

PIO-4  card  (for  configuration  interfacing 
to  status  advisory  displays  only) 

(1) 

j 


- 


t 


■ 
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5. 7. 2. 3 Control  Structure 

The  objective  of  this  paragraph  is  to  define  a general  control  structure  that 
will  efficiently  control  the  timely  execution  of  avionic  processes  in  a multiple 
computer  avionic  system.  This  structure  is  defined  in  terms  of  a number  of 
primitive  functions  which  the  control  mechanism  must  perform  and  a set  of 
parameters,  associated  with  each  applications  process,  on  which  these  primi- 
tive functions  operate.  In  concept,  the  capability  to  execute  the  primitive  func- 
tions must  be  available  within  each  computer  that  executes  more  than  one  process. 
Microcomputers  that  repetitively  execute  the  same  process  may  be  considered 
as  functional  units  and  do  not  require  the  ability  to  execute  the  primitive  functions. 
Most  of  the  implementation  structure  defined  in  this  paragraph  follows  the  struc- 
ture recommended  in  References  4 and  14. 

5.7.2.  3. 1 Control  Parameters.  The  following  is  a list  of  control  parameters 
that  must  be  available  to  each  computer  for  each  process  that  it  may  execute. 
These  parameters  will  be  stored  in  a table  which  is  accessed  by  the  control 
mechanism  when  each  process  becomes  active. 

a.  Task  Identifier.  A unique  process  name  on  identifier 

b.  Dependency  Tree.  If  a process  generates  one  or  more  successor  proc- 
esses the  task  identifiers  of  all  successor  processes  and  their  relative 
positions  in  the  hierarchical  structure  make  up  the  dependency  tree. 
Process  B is  considered  a successor  of  process  A in  the  case  in  which 
process  B may  be  executed  only  if  process  A has  been  completed. 

c.  Process  Authorities.  This  parameter  limits  the  authority  of  a process 
to  define  for  itself  and  its  successor  the  processor,  memory,  sema- 
phores, and  event  responses  it  will  use. 

d.  Dispatch  Type.  Defines  whether  a process  is  synchronous,  demand, 
background,  or  demand/synchronous 


5-40 


NADC-79161-40 


> 

: 

, 

i : 

i : 


e.  Process  State.  Defines  the  current  state  of  the  process  (ready,  sus- 
pended ready,  waiting,  suspended  waiting,  running,  or  requesting  execu- 
tive service) 

f.  Dispatching  Priority 

g.  Storage  Translation  Table.  All  memory  in  the  system  is  considered 

as  a contiguous  virtual  memory.  This  table  contains  the  real  addresses 
of  the  variables  addressed  virtually  by  the  process.  It  also  contains 
other  information,  such  as  the  protection  constraints  on  the  variable 
and  whether  the  required  data  segment  is  local  to  the  computer  in  which 
the  process  is  executing  or  in  the  memory  of  a remote  computer.  Per- 
forming this  translation  is  not  possible  at  system  generation  time,  since 
the  real  addresses  of  data  may  change  during  the  mission  as  a result 
of  reconfiguration  after  failure.  In  addition,  once  a data  word  is  brought 
into  the  local  memory  of  the  process,  its  status  changes  from  remote 
to  local;  and  future  references  can  be  made  much  more  efficiently. 

The  storage  translation  table  is  initialized  at  system  generation  time 
and  changed  by  the  control  mechanism  as  required. 

h.  Processor  Identifiers.  Identifiers  of  the  physical  processors  in  which 
the  process  may  run 

i-  Semaphore  Descriptors.  Each  resource  has  a semaphore  associated 
with  it  which  will  indicate  whether  the  resource  is  available  or  unavail- 
able. This  parameter  indicates  which  semaphores  are  used  by  the 
process. 

j.  Process  Status.  Contains  state  information  necessary  for  the  process 
to  run  in  the  computer.  This  information  usually  consists  of  status 
and  working  register  contents  as  well  as  the  values  of  any  variables 
that  must  be  initialized. 

k.  Event  Response  Descriptors.  For  each  event  that  the  process  may 
implicitly  or  explicitly  cause,  the  event  identifier,  the  allowable 
processor(s),  the  event  type,  and  the  semaphore  descriptors  for  that 
event  must  be  listed. 

l.  Termination  Event  Identifiers.  Each  process  causes  the  identified 
event  as  it  terminates. 

m.  Failure  Parameters.  This  entry  contains  information  indicating  which 
alternate  process,  if  any,  is  to  be  executed  for  each  particular  class 
of  failures  that  has  been  anticipated  in  the  system  design. 

n.  Interrupt  Identifiers.  Identifies  interrupts  honored  by  the  process 
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5. 7.2. 3. 2 Control  Primitives.  The  following  is  a list  of  primitive  control  func- 
tions that  are  assumed  to  be  resident  at  each  computer  and  available  to  each 
process  as  it  executes.  These  control  primitives  are  executed  via  calls  from 
the  process  to  the  control  mechanism,  similar  to  the  Executive  Service  Request 
of  the  SDEX-M  operating  system.  Using  these  primitives,  applications  programs 
can  be  written  to  implement  the  control  functions  outlined  in  paragraph  3.2.2. 4. 

a.  Create/Destroy  Process.  This  primitive  is  used  to  build  or  purge  a 
table  containing  all  the  parameters  listed  in  paragraph  5. 7. 2. 3. 1. 

b.  Define/Modify  Attribute  of  Process.  This  primitive  adds  or  modifies 
one  of  the  data  parameters  specific  to  a process.  The  data  parameters 
are  as  defined  in  paragraph  5.  7. 2.3.1. 

c.  Define  Resource.  A resource  is  a processor,  a segment  of  physical 
storage,  a semaphore,  or  an  event.  This  primitive  identifies  and 
bounds  a resource  needed  for  execution  by  the  calling  process  or  one 
of  its  successor  modules. 

d.  Relinquish  Resource.  This  primitive  releases  a previously  defined  re- 
source so  that  it  may  be  used  by  another  process. 

e.  Define /Modify  Attribute  of  Resource.  This  primitive  defines  or  modi- 
fies the  type  or  quantity  of  a resource  needed  by  either  the  process 
executing  the  primitive  or  one  of  its  successor  processes. 

f.  Define/Modify  Sharing  of  Resource.  This  indicates  which  resources  may 
be  shared  among  successor  processes  identified  in  the  primitive  call. 

g.  Delegate/Rescind  Authority.  This  primitive  enables  the  process  calling 
the  primitive  to  convey  to  any  successor  processes  the  ability  to  execute 
any,  some,  or  all  of  the  previously  described  "Define"  primitives. 

h.  Block/Release  Process.  This  is  used  to  stop  another  process  or  remove 
the  stop,  making  it  eligible  for  dispatch. 

i.  Semaphore  Block/ Semaphore  Release.  Semaphores  are  used  in  the 
normal  manner  to  indicate  the  availability  of  resources.  The  sema- 
phore block/ release  primitives  are  used  to  control  access  to  these  re- 
sources by  processes. 

j.  Request  Status  From . This  primitive  is  used  to  request  messages  or 
status  from  a process  suspended  by  an  event. 

k.  Update  Status  Of.  Used  to  update  the  status  of  a suspended  process  and 
release  the  suspension.  This  primitive  and  the  request  status  primitive 
are  used  to  transmit  and  receive  messages  between  processes. 
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The  primitives  described  above  may  be  broken  into  three  general  categories: 
process  control,  which  is  the  management  of  the  suspended,  ready,  and  execu- 
tion states  of  processes;  definition,  by  which  processes  identify  resource  needs 
and/or  disperse  resources  from  tneir  own  pool  to  their  descendant  processes; 
and  authority,  by  which  processes  convey  to  descendant  processes  the  ability  to 
execute  definition  primitives. 

The  formats  for  these  primitives  are  shown  in  Table  5-16. 


TABLE  5-16.  FORMAT  OF  PRIMITIVE  OPERATORS 


Process  Primitives 


Block/  Re  lease 

Process  (N) 

Semaphore  Block 

Process  (N) 

Semaphore  Release 

Process  (N) 

Definition  Primitives 

Create/Destroy 

Process  (N) 

Define/Modify 

Attribute  (N) 

of  Process  (N) 

Define  / Re  linqui  sh 

Resource  (N) 

of  Process  (N) 

Define/Modify 

Attribute  (N) 

of  Process  (N) 

of  Process  (N) 

Define/Modify 

Sharing 

of  Resource  (N) 

between  Proc- 
esses (N)  (N) 

Authority  Primitives 

(Delegate/Rescind  Authority  for) 

Create/Destroy 

of  Processes 

to/from  Process  (N) 

Define/Modify 

of  Attribute 

to/from  Process  (N) 

Define/Re  linqui  sh 

of  Resource 

to/from  Process  (N) 

Define/Modify 

of  Attribute 

of  Resource  (N) 

to/from  Process 
(N) 

De  fine  / Re  linqui  sh 

of  Sharing 

of  Resource  (N) 

to/from  Process 

(N) 
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5. 7. 2.  3.  3 Implementation  of  Control  Functions.  Using  the  control  parameters 
?nH  primitive  operators  defined  in  5. 7. 2. 3.1  and  5. 7. 2. 3. 2,  configuration- 
unique  application  programs  can  be  written  for  control  purposes.  For  each 
application  process,  a kernel  executive  and  a process  description  table  are  de- 
fined. The  kernel  executive  is  a body  of  common  control  functions  which  con- 
trol the  interfaces  between  hardware  and  software  and  between  software  modules. 
It  has  three  primary  functions:  execution  of  primitives,  management  of  re- 
sources (by  assigning  them  to  processes  and  reclaiming  them  as  necessary  to 
support  execution  time  demands),  and  cooperation  with  other  kernel  executives 
for  the  purpose  of  executing  primitives  requested  by  remote  processes  or  for 
performing  process  or  resource  reassignment.  The  process  description  table 
is  a process  control  record  containing  the  control  parameters  described  pre- 
viously; this  table  is  used  to  describe  a process  and  the  process's  status,  re- 
source needs,  and  authority  to  change  the  process  description  table  of  itself  or 
its  successor  modules. 

The  kernel  executive  and  its  operations  using  the  process  description  table 
are  the  mechanisms  by  which  application  programs  may  affect  the  state  of  the 
multiple  computer  system.  Thus,  for  each  function  listed  in  Table  4-1,  a con- 
configuration-unique  application  program  can  be  written  which  will  use  the  de- 
fined primitives  within  the  normal  software  structure  to  implement  that  particu- 
lar function  and  communicate  with  the  other  functions  when  necessary. 

The  control  structure  described  above  has  two  main  components  for  each 
node.  These  are  the  kernel  executive,  which  is  the  control  mechanism  itself; 
and  the  process  description  table,  which  is  the  data  set  on  which  the  kernel 
executive  operates.  The  primitive  functions  themselves  are  executed  upon  re- 
quest from  the  application  programs. 

The  above  structure  is  fairly  well  implemented  in  the  present  SDEX/M 
executive  definition,  with  the  exception  that  SDEX/M  controls  only  a single 
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computer.  However,  the  necessary  multiple-computer  primitive  functions  could 
be  added  to  the  SDEX/M  definition,  or  the  present  single-computer  executive 
functions  could  be  expanded  to  include  the  multiple-computer  case.  This  expan- 
sion of  the  SDEX/M  executive  into  a multiple-computer  executive  via  expansion/ 
addition  of  multiple-computer  primitive  functions  is  recommended  for  the  fol- 
lowing reasons: 

a.  SDEX/M  is  already  designated  the  standard  executive  for  the  AN/AYK-14. 

b.  The  structure  of  SDEX/M  can  be  expanded  to  cover  the  structure  de- 
fined in  paragraph  4. 4 with  only  moderate  cost. 

c.  A full  software  implementation  of  the  control  structure  will  provide  the 
maximum  flexibility  and  growth  potential  for  the  system.  This  flexi- 
bility and  growth  are  obtained  at  considerable  cost  in  performance, 
since  the  most  often  used  control  primitives  should  be  implemented  in 
hardware  to  assure  maximum  speed.  However,  the  BASIC  configura- 
tion can  "grow  into"  these  hardware  implementations  if  the  laboratory 
is  required  to  simulate  a particular  platform  with  well-defined  execu- 
tive requirements.  Presentlv,  the  flexibility  provided  by  a software 
implementation  outweighs  the  performance  degradation  that  results 
from  it. 

The  communication  structure  can  also  be  implemented  in  software  at  moderate 
cost.  The  application  requirements  can  be  met  using  software  developed  from 
the  bus  control  functions  defined  by  the  Digital  Avionics  Information  System 
(DAIS)  program.  This  software  can  be  viewed  as  an  implementation  of  the  re- 
quest status  and  update  status  primitives  defined  in  paragraph  5.  7. 2. 3.  2 of  this 
report.  Again,  these  functions  could  later  be  implemented  in  hardware  or  firm- 
ware if  the  platform- unique  application  requirements  demand  it. 

5. 7. 2.  4 Software  Configuration 

The  software  for  the  recommended  architecture  falls  into  two  general  areas: 
applications  software  and  control  (or  executive)  software.  The  structure  recom- 
mended for  the  control  software  has  been  described  above,  and  the  application 
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software  structures  are  represented  by  the  DU’s  defined  in  paragraph  3. 2. 1.2. 
The  objective  of  this  paragraph  is  to  define  an  implementation  of  the  applica- 


tion  software  structure. 

The  DU's  previously  described  are  to  be  implemented  in  software.  However, 
for  the  purposes  of  demonstration  in  the  BASIC  laboratory,  the  DU’s  need  not 
reflect  the  actual  processing  done  on  the  S-3A.  They  need  only  reflect  the 
processing  time  used  and  the  messages  either  received  or  transmitted  by  the 
process.  The  majority  of  processing  time  is  used  by  periodic  processes,  and 
the  majority  of  bus  time  is  used  in  transmitting  periodic  messages.  Secondary 
system  loading  effects  occur  because  of  asynchronous  messages  and  demand 
tasks. 

Table  5-2  presents  the  software  allocation  structure  for  the  recommended 
architecture,  and  the  relationships  between  the  software  functions  and  the 
bus  messages  are  presented  in  Table  5-17.  This  table  provides  general  param- 
eters which  can  be  used  in  the  simulation  of  the  recommended  architecture  via 
the  GCSS  simulator.  The  node  and  message  identifiers  in  Table  5-17  represent 
the  message  structure  provided  in  Table  5-3  of  this  report.  Software  functions 
'DU's)  not  included  in  Table  5-17  do  not  have  inputs  or  outputs. 

5. 7. 2.  5 System  Operation 

Figure  5-7  shows  the  recommended  fault  tolerant  configuration  for  a com- 
plete BASIC  laboratory  model.  All  nodes  are  AN/AYK-14  configuration  XN-1 
or  XN-2  computers.  All  buses  are  implementations  of  MEL-STD-1553.  The 
display  subsystem  is  configured  according  to  AIDS  specifications.  Interfaces 
between  subsystems  and  buses  are  assumed  to  be  controlled  by  standard  micro- 
processors (one  for  each  bus).  One  of  the  microprocessors  would  be  in  standby 
mode,  only  operating  if  a failure  occurred  in  the  other.  An  example  of  system 
operation  with  emphasis  on  fault  detection,  isolation,  and  reconfiguration  will 
be  given  in  the  following  paragraphs. 

■ 
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TABLE  5-17.  DU  - MESSAGE  RELATIONSHIPS  (Sheet  1 of  3) 


SRC 

DU 

SRC 

NODE 

XMT 

SUB 

ADR 

DST 

DU 

DST 

NODE 

RCV 

SUB 

ADR 

4c  4c  4c 

♦ 

1 

10 

2 

22 

32 
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4c 

1 

10 

3 

22 

82 

2 

★ 

1 

10 

6 

111 

111 

1 

4c 

4 

10 

1 

43 

70 

1 

4c 

5 

40 

30 

22 

32 

30 

* 

6 

40 

1 

11 

50 

1 

♦ 

6 

40 

4 

100 

100 

1 

♦ 

5 

2 

* 

6 

40 

30 

34 

10 

30 

* 

8 

40 

7 

122 

122 

1 

4c 

9 

40 

2 

22 

32 

13 

4c 

3 

14 

4c 

9 

40 

6 

119 
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1 

4c 

10 

50 

1 

6 

40 

1 

4c 

10 

50 

30 

6 

40 

30 

4c 

10 

50 

30 

22 

82 

30 

4* 

11 

50 

2 

43 

70 

3 

4c 

3 

4 

4c 

13 

40 

3 

43 

70 

5 

4c 

13 

40 

9 

22 

a2 

15 

4c 

14 

30 

1 

22 

82 

6 

4c 

14 

30 

30 

115 

115 

30 

4c 

15 

30 

2 

22 

32 

7 

4c 

3 

3 

4c 

4 

9 

4c 

5 

10 

4c 

6 

11 

4c 

7 

12 

4c 

15 

30 

30 

9 

40 

30 

4c 

17 

30 

30 

22 

82 

30 

4c 

17 

30 

30 

43 

70 

30 

4c 

18 

22 

105 

105 

4* 

30 

30 

4c 

19 

22 

2 

22 

32 

5 

* 

19 

22 

3 

105 

105 

1 

4c 

19 

22 

30 

21 

10 

30 
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TABLE  5-17.  DU  - MESSAGE  RELATIONSHIPS  (Sheet  2 of  3) 


SRC 

SRC 

XMT 

SUB 

ADR 

DST. 

DST 

RCV 

SUB 

ADR 

DU 

NODE 

DU 

NODE 

*** 

* 

22 

82 

5 

24 

81 

1 

♦ 

6 

2 

♦ 

7 

3 

♦ 

8 

4 

♦ 

9 

5 

* 

10 

6 

* 

11 

7 

* 

24 

81 

101 

101 

* 

24 

81 

102 

102 

* 

24 

81 

103 

103 

* 

24 

81 

104 

104 

* 

25 

32 

1 

46 

10 

1 

★ 

25 

32 

2 

19 

22 

2 

* 

25 

32 

3 

7 

40 

3 

* 

25 

32 

30 

9 

40 

30 

* 

25 

32 

30 

10 

50 

30 

♦ 

25 

32 

30 

12 

40 

30 

* 

25 

82 

30 

17 

30 

30 

* 

25 

32 

30 

13 

22 

30 

* 

25 

82 

30 

29 

70 

30 

♦ 

25 

82 

30 

32 

21 

30 

* 

25 

82 

30 

45 

10 

30 

♦ 

27 

70 

1 

1 

10 

3 

♦ 

27 

70 

2 

46 

10 

6 

* 

27 

70 

3 

32 

21 

1 

* 

27 

70 

5 

19 

22 

1 

♦ 

27 

70 

6 

15 

30 

1 

* 

27 

70 

7 

17 

30 

2 

♦ 

27 

70 

3 

3 

40 

2 

♦ 

27 

70 

9 

11 

50 

2 

* 

27 

70 

10 

22 

32 

16 

* 

11 

17 

* 

12 

18 

♦ 

27 

70 

30 

21 

10 

30 

* 

27 

70 

30 

22 

32 

30 

* 

30 

22 

1 

32 

10 

2 

* 

32 

21 

1 

40 

10 

1 

♦ 

32 

21 

2 

43 

70 

2 
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TABLE  5 

-17.  DU  - 

MESSAGE 

RELATIONSHIPS 

(Sheet  3 of  3) 

SRC 

SRC 

XMT 

RCV 

SUB 

DST 

DU 

DST 

NODE 

SUB 

DU 

NODE 

ADR 

ADR 

*** 

* 

3 

3 

* 

4 

4 

* 

5 

5 

* 

6 

6 

* 

7 

7 

* 

32 

21 

30 

22 

82 

30 

* 

33 

21 

3 

117 

117 

1 

* 

35 

10 

30 

116 

116 

30 

* 

36 

10 

30 

37 

70 

30 

* 

42 

82 

12 

108 

108 

1 

* 

42 

32 

30 

43 

70 

30 

* 

43 

70 

4 

32 

21 

23 

* 

43 

70 

13 

23 

82 

19 

* 

14 

20 

* 

15 

21 

* 

43 

70 

17 

42 

82 

23 

* 

43 

70 

30 

34 

10 

30 

* 

44 

70 

16 

22 

82 

22 

* 

45 

10 

30 

22 

82 

30 

♦ 

100 

100 

9 

6 

40 

4 

* 

9 

5 

* 

105 

105 

14 

19 

22 

3 

♦ 

106 

106 

15 

28 

70 

8 

★ 

107 

107 

16 

37 

70 

9 

* 

108 

103 

17 

42 

82 

24 

♦ 

110 

110 

19 

28 

70 

10 

♦ 

111 

111 

20 

1 

10 

5 

* 

112 

112 

21 

28 

70 

11 

♦ 

113 

113 

22 

28 

70 

12 

* 

114 

114 

23 

28 

70 

13 

* 

115 

115 

24 

15 

30 

2 

♦ 

117 

117 

26 

21 

30 

* 

123 

123 

1 

25 

82 

30 

* 

124 

124 

1 

25 

82 

30 

♦ 

125 

125 

1 

25 

32 

30 

* 

126 

126 

1 

25 

82 

30 

3 
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5.7.2.  5. 1 System  Initialization.  Upon  application  of  power,  all  of  the  AN/ 
AYK-14's  and  microprocessors  would  automatically  initiate  a firmware  self- 
check program.  This  test  would  culminate  in  an  attempt  to  communicate  its 
status  with  the  bus  control  executive  program  which  would  be  resident  in  the 
reconfiguration  monitor  node.  The  reconfiguration  monitor  would  be  the  processor 
in  control  of  the  initialization  process.  Its  self-check  process  complete,  this 
processor  would  then  attempt  to  load  its  memory  from  the  computer  control  unit 
(CCU)  or  loader/verifier  units.  If  this  is  successful,  the  reconfiguration  moni- 
tor node  would  then  assume  control  of  the  main  system  bus  and  begin  execution 
of  the  bus  control  process.  If  the  various  units  are  operational,  the  reconfigura- 
tion monitor  will  then  supervise  the  loading  of  the  various  computers  from  the 
bulk  store  unit,  if  necessary.  (The  microcomputers  may  have  firmware  pro- 
grams.) Initially,  diagnostic  programs  will  be  loaded  and  executed,  with  re- 
sults sent  back  to  the  reconfiguration  monitor.  If  all  diagnostic  tests  are  posi- 
tive, the  operational  programs  will  be  loaded;  and  execution  will  begin. 

5.7.2.  5.2  On-line  Detection.  Continuous  built-in  test  equipment  ;BITE)  hard- 
ware in  the  AN/AYK-14  will  monitor  the  functions  listed  in  Table  5-1S.  On-line 
detection  is  not  presently  implemented  for  any  commercially  available  micro- 
computer. 

5.7.2.  5.3  Scheduled  Test.  The  AN/AYK-14  in-flight  performance  monitoring 
(IFPM)  program  responds  to  an  interrupt  periodically  generated  by  the  hardware 
built-in-test  (BIT)  timer  and  is  specified  to  detect  98  percent  of  all  faults  in  the 
system.  In  addition  to  the  IFPM  modules,  generation  of  a periodic  message  to 
the  remainder  of  the  system  indicating  the  status  of  the  computer  will  be  neces- 
sary. If  this  message  is  not  properly  transmitted  and  received  by  the  rest  of 
the  system,  assume  that  the  computer  has  failed. 

The  microcomputers  in  the  system  should  also  perform  a periodic  self- 
test function  and  generate  status  messages  to  the  system.  Where  two  redundant 
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TABLE  5-18.  AN/AYK-14  HARDWARE  BITE 


• Memory  Parity 

• Memory  Protect 

• Memory  Channel  Timeout 

• Power  Monitoring 

• Overtemperature  Monitoring 

• Bus  Timeouts 

• I/O  Channel  Parity 

• I/O  Channel  Timeout 

• Manchester  Code  Format  Verification 

• BIT  Timer 

• BIT  Indicator 

microcomputers  perform  the  same  interface  function  (for  different  buses),  their 
self-test  programs  and  status  messages  should  be  identical  so  they  can  be  com- 
pared by  one  or  more  receiving  monitors  and  so  faults  can  be  more  easily  de- 
tected and  isolated. 

5.7.2.  5.4  Redundancy  Testing.  The  primary  redundant  resources  in  the  sys- 
tem are  the  reconfiguration  monitor  node,  the  redundant  interface  microcom- 
puters, the  redundant  1553  buses,  and  extra  memory  modules  in  all  the  AN/ 
AYK-14  computers.  The  reconfiguration  monitor  is  testing  itself  periodically 
and  generating  a status  message  which  is  to  be  sent  to  all  other  nodes.  The 
redundant  interface  microcomputers  are  conducting  self-test  programs  periodi- 
cally and  sending  status  messages  over  their  respective  buses  to  either  the  re- 
configuration monitor  or  to  the  computer  controlling  the  secondary  bus.  The 
bus  controller  receives  both  of  the  status  messages  and  compares  them  to  deter- 
mine the  status  of  the  microcomputers.  The  redundant  buses  are  tested  every 
time  a message  is  transferred  over  them.  If  repeated  errors  occur  within  mes- 
sages transmitted  from  different  sources,  assume  that  the  bus  is  faulty. 
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5. 7. 2. 5.5  Isolation 
CPU/IOP  Failures 

If  a CPU  or  an  IOP  of  an  AN/AYK-14  or  the  CPU  of  a microcomputer  fails, 
then  the  entire  unit  must  be  isolated  from  the  remainder  of  the  system.  If  the 
failure  has  not  occurred  in  a unit  which  is  a bus  controller,  isolation  can  be  ac- 
complished by  the  appropriate  bus  controller  program;  the  bus  controller  pro- 
gram will  merely  refuse  to  read  from  or  write  to  the  faulty  unit.  If  the  failure 
is  such  that  the  bus  is  not  usable,  that  bus  may  be  considered  as  failed  and  may 
switch  to  its  backup  bus.  Alternatively,  removal  of  power  from  the  faulty  unit 
may  be  possible  to  determine  if  the  bus  is  usable.  If  the  Advanced  Aircraft  Elec- 
trical System  (AAES)  is  providing  electrical  power,  power  removal  can  be  ef- 
fected by  an  appropriate  request  to  the  AAES  control  computer.  Otherwise, 
special-purpose  hardware  must  be  employed. 

If  a CPU  fails  in  one  of  the  units  that  is  a secondary  bus  controller,  the 
reconfiguration  monitor  will  be  informed  of  this  via  status  messages  of  the 
tailed  units  and  any  AN/AYK-14  units  that  connect  to  the  same  secondary  bus. 

The  reconfiguration  monitor  will  then  prepare  the  backup  computer  to  assume 
the  duties  of  bus  controller  for  the  secondary  bus;  shut  down  the  faulty  computer 
by  means  of  a signal  on  a discrete  wire;  and  signal  the  backup  computer,  via 
the  bus,  to  inititate  bus  control  functions. 

If  a failure  occurs  in  the  reconfiguration  monitor  (which  is  the  bus  controller 
for  the  main  system  bus),  this  situation  will  be  made  known  to  the  rest  of  the 
system  via  the  status  messages  (or  lack  of  them)  from  the  reconfiguration  moni- 
tor. Discretes  from  three  of  the  other  AN/AYK-14  computers  will  activate  a 
majority  voting  circuit  which  will  shut  down  the  reconfiguration  monitor  when 
any  two  of  the  three  discrete  signals  are  enabled.  One  of  the  other  AN/AYK-14's 
will  then  begin  executing  the  prestored  bus  controller  program. 
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Memory  Failures 

A memory  failure  in  an  AN/AYK-14  will  be  detected  by  BIT  and/or  the  IFPM 
and  will  be  signaled  by  an  interrupt.  In  any  case,  the  faulty  module  will  be  iso- 
lated by  an  interrupt- service  routine  which  will  prevent  access  to  that  module 
until  reconfiguration  recovery  can  be  effected.  If  the  memory  of  a microcom- 
puter fails,  the  entire  microcomputer  will  be  isolated. 

I/O  Channel  Failures 

The  interface  microcomputers  will  make  reasonableness  checks  on  their 
sensor  subsystem  input  as  often  as  is  feasible.  If  the  input  appears  in  error, 
the  microcomputers  will  notify  the  bus  controller  by  means  of  a status  message. 
The  bus  controller  will  compare  this  condition  with  that  of  the  microcomputer 
on  the  other  bus.  If  both  messages  agree  that  the  sensor  data  are  in  error,  die 
bus  controller  will  not  allow  any  more  data  transmission  from  that  sensor. 

5. 7. 2. 6 Recovery 

5. 7. 2. 6. 1 CPU/IOP  Failures.  If  an  entire  computational  unit  has  been  isolated 
from  its  interfaces,  then  the  operational  processes  previously  performed  by 
that  unit  must  be  executed  elsewhere.  The  unit  that  executes  these  added 
processes  must  have  the  following  characteristics: 

a.  The  unit  must  have  access  to  the  peripherals/interfaces  of  the  failed 
machine. 

b.  It  must  have  access  to  the  program  code  which  performs  the  same 
function  as  the  processes  executed  by  the  failed  machine. 

c.  It  must  have  memory  sufficient  to  store  the  extra  code. 

d.  It  must  have  available  time  to  execute  the  extra  code. 

If  one  of  the  microcomputers  has  failed,  the  redundant  microcomputer  will 
replace  it.  The  redundant  microcomputer  has  the  same  interfaces  as  its  failed 
counterpart.  The  appropriate  code  has  been  prestored  in  its  memory,  and  it 
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will  execute  this  program  as  its  highest  priority,  thus  ensuring  that  sufficient 
time  will  be  available.  The  self-test  programs  will  continue  to  execute,  but  at 
a lower  iteration  rate.  If  Nodes  10,  21  and  22,  30,  or  50  fail,  they  will  be  re- 
placed by  the  reconfiguration  monitor.  The  reconfiguration  monitor  will,  upon 
indication  that  the  node  has  been  successfully  isolated,  load  itself  with  the 
appropriate  programs  from  the  bulk  store.  All  required  data  will  be  marked 
"nonresident"  in  the  data  translation  tables,  and  the  programs  will  start  execu- 
tion at  the  beginning  of  the  next  major  cycle.  Self-test  programs  and  bus  control 
will  continue  on  the  reconfiguration  monitor,  but  the  iteration  rate  will  be  lower. 

If  Nodes  40,  70,  31,  or  32  fail,  they  will  be  replaced  by  Nodes  50,  21,  32, 
and  31,  respectively,  so  that  access  to  the  proper  interfaces  will  be  maintained. 
If  Nodes  40  and  70  do  not  have  the  capability  to  execute  the  extra  processes  as 
well  as  their  own  operational  processes,  it  may  be  necessary  to  perform  a dual 
reconfiguration  using  the  reconfiguration  monitor.  For  example,  if  Node  70 
fails,  it  must  be  replaced  by  Node  21  or  22,  since  only  these  nodes  have  the 
proper  interfaces.  However,  if  Node  21  cannot  perform  both  sets  of  processes, 
then  the  reconfiguration  monitor  must  be  used  to  replace  Node  21.  Nodes  50, 

21,  and  22  have  no  operational  interface  with  their  respective  secondary  buses 
and  are  only  connected  to  those  secondary  buses  for  purposes  of  reconfiguration. 

The  reconfiguration  monitor  performs  no  operational  function  other  than  bus 
control.  Therefore,  bus  control  is  the  only  function  transferred  if  the  reconfigu- 
ration monitor  fails. 

The  bulk  store  again  performs  no  operational  function  and  so  requires  no 
reconfiguration  process.  However,  implementation  of  the  bulk  store  in  a num- 
ber of  small  modules  may  be  more  desirable  to  reduce  the  probability  of  a 
total  failure. 

In  general,  the  replacement  process  proceeds  as  follows:  an  interrupt  will 
be  generated  in  the  replacement  computer;  the  required  programs  will  be  read 
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into  the  replacement  unit  from  the  bulk  store;  the  control  parameters  (iteration 
rates,  priorities,  etc.)  will  be  given  to  the  executive  program  from  the  same 
bulk  store  — these  are  predefined  for  each  type  of  failure;  all  data  required  by 
the  program  will  be  marked  "nonresident";  system  variables  will  be  updated  by 
the  global  executive  to  reflect  the  new  configuration;  the  interrupted  program 
will  be  gracefully  aborted;  and  the  program  with  the  highest  local  dispatch  priority 
will  begin  execution  in  the  replacement  computer. 

5. 7.2.6. 2 Memory  Failures.  If  a memory  fails  in  a microcomputer,  it  should 
be  treated  as  a CPU  failure  as  described  above.  If  the  memory  module  in  an  AN/ 
AYK-14  fails,  it  will  be  replaced  by  a resident  spare  memory  module.  If  the 
failed  segment  contained  program  code  or  constants,  these  should  be  replaced 
from  data  in  the  bulk  store. 

Variable  data  will  be  lost  and  must  be  regenerated.  For  this  reason,  storing 
important  and  slowly  changing  data,  such  as  system  track  data,  in  two  computers 
may  be  desirable  to  assure  that  these  data  can  be  recovered  quickly  in  the  case 
of  a memory  failure. 

5. 7. 2.  6. 3 I/O  Failures.  The  primary  mechanism  for  recovery  from  I/O  fail- 
ures is  the  automatic  switchover  to  the  redundant  bus,  as  provided  for  by  the 
1553  bus  structure  and  bus  control  software. 


5. 7. 2. 7 Conclusions 

This  section  has  presented  a recommended  system  configuration  for  BASIC 
and  the  rationale  for  developing  this  configuration.  First,  the  decompositional 
units  derived  from  the  S-3A  functional  requirements  were  grouped  into  related 
functional  areas  and  assigned  to  processing  nodes.  The  data  flow  among  the 
nodes  was  extensively  analyzed,  and  a set  of  1553  messages  was  defined  to 
accommodate  this  data  flow.  The  data  rate  resulting  from  this  message  struc- 
ture was  calculated  and  found  to  be  moderate,  allowing  a wide  growth  margin 
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before  new  buses  must  be  added.  The  processing  requirements  for  each  node 
were  analyzed  and  a hardware  configuration  for  the  node  developed.  Software 
execution  parameters  were  defined  and  presented  in  a format  suitable  for  input 
to  a hardware-on- software  simulation  effort. 

Finally,  an  example  of  overall  system  operation  was  presented,  with  empha- 
sis on  fault  tolerance  and  reconfiguration. 


NADC-79161-40 
SECTION  6 

IMPLEMENTATION  SUBSET 


6.1  OBJECTIVE 

The  objective  of  this  section  is  to  define  a subset  of  the  recommended  arch- 
itecture which  may  be  implemented  in  a short  time  with  reasonable  cost  and  which 
will  demonstrate  and  verify  the  major  concepts  embodied  in  the  full  architecture. 

The  subset  defined  in  this  section  will  demonstrate  both  flexibility  and  fault 
tolerance  and  will  provide  an  indication  of  the  capability  of  the  full  architecture 
in  the  following  areas: 

• Computational  power 

• Operator  interface 

• Control  mechanism  efficiency 

• Communication  mechanism  efficiency 

In  addition  to  the  demonstration  aspects,  the  configuration  recommended  will 
be  available  to  provide  system  integration  services  to  both  subsystem  technology 
developers  and  system  platform  users. 

Funding  and  time  constraints  dictate  that  the  configuration  recommended 
contain  only  available  hardware  and  that  software  generation  be  held  to  a 
minimum. 

6.2  APPROACH 

In  order  to  make  the  system  as  generic  and  usable  as  possible,  the  subset 
of  the  architecture  shown  in  Figure  6-1  was  chosen.  This  configuration  contains 
modes  used  for  any  avionic  application:  communications  (Node  21),  navigation 
(Node  70),  display  and  control  (Nodes  31  and  32),  and  the  bus  controller  and  re- 
configuration monitor  (Node  90).  In  addition,  the  MAD  mode  (Node  30)  was 
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chosen  because  an  existing  MAD  program,  written  in  SPL/I,  exists  and  can  be 
used  without  major  modification.  In  addition,  Node  30  provides  convenient  growth 
capability  and  may  act  as  a backup  for  Node  90  without  compromising  its  opera- 
tional capability.  The  MAD  subsystem  also  does  not  require  sophisticated,  high- 
speed signal  processing. 

The  flexibility  of  the  system  may  be  demonstrated  through  the  choice  of  those 
subsystems  which  the  nodes  are  to  represent.  For  example,  the  navigation  sub- 
system on  the  S-3A  does  not  contain  IISA  or  ASW  support  aircraft  carrier  (CVS), 
yet  Node  70  simulates  these  systems  at  the  interface  without  modification  of  the 
message  structure  or  data  rates  derived  for  the  full,  S-3A-based  architecture. 
Similarly,  the  bus  interface  defined  for  Node  21  in  the  full  architecture  will  ac- 
commodate the  postulated  Joint  Tactical  Integrated  Data  System  (JTIDS)  interface 
without  modification.  The  AIDS  subsystem  is  also  simulated  at  the  interface  by 
Nodes  SI  and  S2.  Thus,  the  node  partitioning  and  message  structure  derived 
from  the  S-3A-based  requirements  are  flexible  enough  to  accommodate  three 
advanced  technology  subsystems  without  major  modification. 

A limited  amount  of  fault  tolerance  making  maximum  use  of  existing  IFPM 
and  bus  error  processing  routines  is  incorporated  into  the  system.  Provisions 
are  made  for  periodic  system  self-check  and  subsequent  load  of  reconfiguration 
programs,  although  these  programs  are  not  defined  in  detail.  It  is  anticipated 
that  these  programs  will  start  out  very  simple  and  be  made  more  sophisticated 
as  experience  is  gained  with  the  system.  Bus  traffic  and  conflicts  can  be  meas- 
ured and  compared  against  those  predicted  by  analysis  and  simulation  in  order 
to  aid  in  the  evaluation  of  the  architecture. 

In  terms  of  service  to  users,  several  new  technology  subsystems  (.AIDS, 

TIES,  nSA)  can  be  simulated  in  more  detail  and  eventually  incorporated  into  the 
recommended  system. 
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After  selection  of  a configuration,  a simple  scenario  was  chosen  as  a dem- 
onstration problem.  The  scenario  was  abstracted  from  the  set  of  operational 
sequence  diagrams  (Appendix  B)  developed  for  use  by  the  V/STOL  program. 

These  operational  sequence  diagrams  depict  the  interactions  between  the  oper- 
ators and  the  avionic  subsystems  for  a V/STOL  Type  A aircraft  ASW  mission. 

The  abstracted  sample  problem  is  considerably  simplified  (therefore,  unrealistic) 
because  of  hardware  and  manpower  constraints,  but  it  may  serve  as  a starting 
point  for  a more  realistic  demonstration  if  desired. 

In  order  for  the  scenario  to  be  useful,  it  must  include  human  interaction. 
Therefore,  the  scenario  cannot  be  entirely  predefined  but  must  include  asynchro- 
nous responses  to  operator  Keyset  inputs.  The  next  step  in  the  demonstration, 
then,  was  the  definition  of  the  allowable  operator  inputs  and  the  responses  to 
them.  This,  together  with  the  requirements  for  preprogrammed  synchronous 
message  generation,  led  to  the  definition  of  the  specific  functions  that  must  be 
performed  by  the  modes  in  the  scenario,  and  the  specific  contents  of  the  mes- 
sages passed  over  the  bus. 

Finally,  general  specifications  were  developed  for  the  software  required  to 
implement  the  functions.  In  the  specification  of  the  software,  available  high-level 
language  (HLL)  software  was  specified  where  available,  or  where  nearly  available 
(that  is,  SDEX-M,  Bus  Controller  Software,  AN/AYK-14  IFPM  programs). 
Assume  that  software  will  be  developed  in  HLL  using  structured  programming 
techniques  wherever  feasible. 

6.3  SUBSET  CONFIGURATION 

As  previously  stated,  Figure  6-1  shows  the  selected  subset  configuration. 

In  general,  the  nodes  have  four  major  functions:  they  perform  executive  func- 
tions which  control  the  scheduling  and  dispatching  of  required  programs;  they 
execute  synchronous  and  asynchronous  modules  which  are  necessary  to  the  en- 
action of  the  chosen  scenario;  they  perform  I/O  operations  (which  consist  of  the 
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operator  action;  finally,  they  perform  test  and  recovery  functions.  The  assump- 
tion is  that  the  executive  functions  of  the  AN/AYK-14's  (Nodes  30  and  90)  will  be 


implemented  using  the  SDEX-14  or  SDEX-M  executive.  The  Z-2's  (Nodes  70,  21, 
100  to  126,  81,  and  82)  will  require  that  executive  software  be  generated). 


The  major  synchronous  processes  necessary  for  the  scenario  are  as  follows: 


• Simulation  of  aircraft,  fix,  and  track  position  updates  by  Node  70 

• Display  processing  by  Nodes  81  and  82 

• MAD  processing  by  Node  30 

• Bus  control  by  Node  90 

• Peripheral  I O simulation  by  Nodes  100  to  126 

• JTIDS  I O simulation  by  Node  21 


The  synchronous  L O messages  are  as  defined  in  Table  5-3.  In  general,  the 
data  content  is  meaningless  and  is  only  required  to  determine  bus  utilization. 

The  data  content  is  defined  onlv  for  those  messages  necessarv  for  the  enaction 
of  the  scenario. 


All  the  nodes  execute  self-test  programs  every  minor  cycle  and  format  the 
results  into  a self-test  message  sent  to  Node  90.  (Node  90  sends  a self-test 
message  to  Node  30. ) If  a failure  is  sensed,  reconfiguration  is  attempted.  Re- 
configuration is  accomplished  by  isolating  the  failed  node  from  the  system  load- 
ing reconfiguration  programs  from  the  mass  memory  into  Node  90  and  reinitial- 
izing Node  90.  If  Node  90  fails,  it  is  isolated  from  the  system,  and  Node  30 
takes  over  the  bus  control  function.  This  bus  control  program  must  be  resident 
in  Node  30  at  all  times  so  that  it  may  communicate  with  the  mass  memory,  if 
possible. 
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6.4  SCENARIO 

6.4.1  Objective 

The  objective  of  this  section  is  to  define  a highly  simplified,  flexible 
scenario  which  will  demonstrate  and  verify  the  performance  of  the  implementa- 
tion subset.  The  scenario  will  be  abstracted  from  the  operational  sequence  dia- 
grams developed  for  the  V/STOL  Type  A ASW  mission  (Appendix  B),  but  the 
hardware  and  time  constraints  prohibit  the  complete  enaction  of  any  signficant 
portion  of  Appendix  A. 1 

6.4.2  Description 

The  recommended  scenario  involves  only  the  TACCO.  He  may  simulate  the 
placement  of  up  to  32  buoys  and  their  type,  either  LOFAR  or  DIFAR.  If  the 
LOFAR  buoys  are  within  a certain  range  of  a simulated  submarine,  a contact 
alert  will  result.  If  a DIFAR  buoy  is  within  a certain  range,  a contact  alert  plus 
a bearing  will  be  displayed.  Convergence  zones  are  ignored.  Fixes  may  be 
entered  and  a track  will  be  displaved  based  on  the  last  three  fixes  on  a single 
contact.  The  objective  of  the  scenario  is  to  obtain  a MAD  contact,  which  will 
occur  if  the  MAD  processing  is  activated  and  the  aircraft  signal  passes  over  the 
submarine  within  a predefined  radius.  There  may  be  more  than  one  target  in 
the  system  which  may  represent  the  same  target  sensed  by  different  subsystems 
at  different  times. 

6.5  SYSTEM  DATA 
6.5.1  Objective 

The  objective  of  this  paragraph  is  to  present  a general  description  of  the 
major  data  structures  that  are  necessary'  for  enaction  of  the  selected  scenario. 
Both  static  data,  which  do  not  change  over  the  course  of  the  scenario,  and 
dynamic  data  are  included. 

^Appendix  A is  not  contained  in  this  volume  but  is  available  from  NAVAIRDEVCEN 
Computer  Systems  Technology  Division,  Code  502. 
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6.5.2  Static  Data 

Static  data  will  normally  not  change  during  a scenario  enaction,  unless  re- 
configuration occurs  because  of  failure.  The  static  data  are  preprogrammed  and 
loaded  at  initialization.  If  reconfiguration  does  occur,  a different  set  of  static 
data  are  loaded  when  specific  nodes  are  reinitialized  to  perform  additional  func- 
tions. There  are  four  major  categories  of  static  data:  program  code,  some 
message  buffers,  initialization  control  data  for  the  executive,  and  the  message 
control  data  base  (PALE FAC)  as  described  in  DAIS  Mission  Software  Product 
Specification  Executive,  Vol.  2,  Bus  Control  SA201302,  of  1 November  1977. 

6.5.2. 1 Program  Code 

Both  normal  and  reconfiguration  programs  must  be  coded  and  resident  in 
the  system.  Normal  programs  are  loaded  at  the  time  of  or  prior  to  system  ini- 
tialization. Reconfiguration  programs  are  loaded  from  the  disk,  through  Node 
21,  and  over  the  MIL-STD-1553  bus  as  required.  A set  of  reconfiguration  pro- 
grams is  postulated  to  exist  for  each  of  the  various  classes  of  failures  that  are 
considered  for  reconfiguration.  Initially,  the  total  failure  and  isolation  from 
the  bus  of  Node  70,  Node  21,  Node  30,  Node  90,  and  Node  32  are  the  only  failure 
classes  considered.  Thus,  there  are  five  program  sets  required;  these  may 
overlap,  as  is  anticipated  in  the  case  of  the  AN  AYK-14's  (Nodes  90  and  30). 

That  is,  most  of  the  normal  program  set  for  Node  30  is  used  as  the  reconfigur- 
ation set  which  Node  90  will  execute  in  its  function  of  Node  30  backup. 

6. 5. 2. 2 Static  Message  Buffers 

Some  of  the  messages  defined  in  Table  5-3  are  not  used  in  the  scenario 
action;  thus,  there  is  no  need  to  either  change  them  or  make  their  contents  mean- 
ingful. Therefore,  the  buffers  should  be  loaded  once  at  initialization  time  and 
thereafter  transmitted  periodically.  Some  predefined  pattern  should  be  loaded 
so  that  correct  operation  may  be  checked  if  desired. 
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6. 5. 2. 3 Initialization  Control  Data 

These  data  are  available  to  the  local  executives  to  control  initialization  (or 
reinitialization)  of  the  nodes.  These  data  include  such  things  as  program  load 
locations,  task  identifiers,  dispatching  type  and  priority,  and  semaphore  linkages. 

6. 5. 2. 4 PALE  FAC  Data  Base 

These  data  are  used  to  control  the  message  structure  over  the  MIL-STD-1553 
bus  and  are  described  in  the  DAIS  Bus  Control  Specification. 

6.5.3  Dynamic  Data 

The  scenario  requires  periodic  position  updates  and  display  of  three  types 
of  objects:  contacts,  sonobuoys,  and  the  aircraft  itself.  In  order  to  enact  the 
scenario,  the  operator  must  enter  both  commands  and  data  via  the  Keyset,  and 
the  displays  must  show  both  symbols  and  alphanumerics.  To  accommodate  these 
requirements,  four  dynamic  file  structures  are  defined:  the  track  contact  file, 
the  fix,  contact  file,  the  sonobuoy  file,  and  the  text  file. 

6 . 5 . 3 . 1 Track,  Contact  File 

The  track/contact  file  contains  the  position,  speed,  heading,  and  so  forth, 
of  the  aircraft  and  any  simulated  targets.  This  file  is  updated  periodically  ac- 
cording to  the  following  rules: 

• If  one  or  more  fly-to  points  iFTP's)  has  been  entered,  the  aircraft  will 
proceed  to  the  first  entered  FTP  at  a preset  speed  and  altitude.  If  the 
FTP  is  reached,  the  aircraft  proceeds  to  the  next  entered  FTP  (if  one 
exists)  or  flies  a circular  pattern  at  a preset  speed,  altitude,  and  radius 
about  the  last  entered  FTP. 

• All  targets  proceed  at  a preselected  heading  at  constant  speed.  If  the 
targets  exit  the  display,  they  start  again  at  a preselected  point.  The 
format  for  track  entries  is  shown  in  Figure  6-2. 

6. 5. 3. 2 Fix/  Contact  File 

Fixes  are  entered  as  a result  of  an  enter  fix  command.  Fix  entries  have  a 
position  indicated  by  the  hook  positions  on  the  display.  If  the  fix  position  is  within 
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a preset  radius  of  a track  in  the  track  file,  the  fix  ID  is  entered  into  the  appro- 
priate position  in  the  track  file  entry.  Three  fixes  entered  into  the  track  file  will 
cause  a track  symbol  to  be  displayed.  The  format  for  a fix  entry  is  shown  in 
Figure  6-2. 

6. 5. 3. 3 Sonobuov  File 

The  sonobuoy  file  contains  the  positions  of  sonobuoys  inserted  into  the  sys- 
tem by  means  of  the  drop  sonobuoy  command.  Sonobuoy  position  is  determined 
by  the  aircraft  position  at  the  time  the  command  is  executed.  The  format  for  a 
sonobuoy  file  is  shown  in  Figure  6-2. 

6. 5. 3. 4 Text  File 

This  file  contains  text  to  be  displayed  f any  or  all  of  the  displays  and  is 
merely  a file  of  ASCII  character  codes,  two  p^r  16-bit  word. 

The  operations  performed  on  these  files  are  described  in  more  detail  in 
paragraph  6.7. 

6.6  FUNCTIONAL  DESCRIPTION  OF  NODES 

6.6.1  Node  70 

6.6. 1.1  General  Description 

Node  70  simulates  the  navigation  and  tracking  subsystem  of  the  full  archi- 
tecture. This  node  calculates  aircraft  position  heading,  pitch,  roll,  and  steering 
information.  It  also  keeps  track  of  sonobuoy  positions  and  contact  and  fix  infor- 
mation. it  transmits  this  information  to  almost  all  other  nodes  in  several  groups 
of  periodic  messages  and  responds  appropriately  to  asynchronous  messages 
(commands)  originating  from  the  Keyset. 

In  the  scenario.  Node  70  simulates  the  position  and  motion  of  the  aircraft 
and  targets,  updates  the  fix  and  sonobuoy  positions,  determines  the  flight  path 
of  the  aircraft,  determines  if  a contact  has  been  made  from  the  relative  position 
of  the  simulated  targets  and  sonobuoys,  and  keeps  time. 


6-10 


NADC-79 16 1-40 


The  hardware  consists  of  an  Interface  Module  (IM),  a Z-2  microcomputer,  and 
and  an  interface  with  the  floppy  disk.  Use  of  this  disk  will  probably  not  be  re- 
quired for  anything  other  than  initial  program  load. 

6.6. 1.2  L O Description 

The  input  and  output  messages  making  up  the  Node  70  interface  in  the  imple- 
mentation subset  are  shown  in  Tables  6-1  and  6-2,  respectively.  Asynchronous 
message  formats  are  dependent  upon  the  particular  command  they  represent  and 
are  described  in  Tables  6-3  and  6-4.  Formats  and  data  content  for  Node  70 
synchronous  input  and  output  messages  are  shown  in  Tables  6-5  and  6-6, 
respectively. 


TABLE  6-1.  NODE  70  INPUT  MESSAGES 
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TABLE  6-2.  NODE  70  OUTPUT  MESSAGES 


The  following  software  module  descriptions  are  intended  to  describe  the 
structure  and  interaction  of  the  software  in  a general  but  comprehensive  manner. 
These  descriptions  are  not  intended  to  be  specifications  but  rather  a general  out- 
line of  what  the  system  is  required  to  do. 


6. 6. 1.3.1  Control  Modules.  Since  the  Z-2  configurations  lack  a preprogrammed 
executive,  they  will  require  an  operating  system  of  sorts.  This  executive  will  be 
required  to  initialize  the  system  (including  the  load  of  relevant  programs  and 
data  from  the  floppy  disk),  to  handle  interrupts,  to  read  and  write  from 
the  bus,  and  to  schedule  and  dispatch  modules.  Figures  6-3  through  6-*  descnoe 
the  executive  functions  implemented  by  software. 
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TABLE  6-3.  NODE  70  COMMAND  INPUTS 
(RCV  SUB  ADR  30) 


COMMAND 

WORD 

NO. 

FORMAT 

CONTENT 

Initialize  NAV 

0 

Bit  String 

Command  ID 

Terminate  NAV 

0 

Bit  String 

Command  ID 

Mark  Time 

0 

Bit  String 

Command  ID 

Read  Latitude,  Longitude 

0 

Bit  String 

Command  ID 

1 

Integer 

X Hook  Position 

2 

Integer 

Y Hook  Position 

Enter  Fix 

0 

Bit  String 

Command  ID 

1 

Integer 

X Hook  Position 

2 

Integer 

Y Hook  Position 

Enter  FTP 

0 

Bit  String 

Command  ID 

i 

Integer 

X Hook  Position 

2 

Integer 

Y Hook  Position 

Recenter 

0 

Bit  String 

Command  ID 

Acknowledge  Contact 

0 

Bit  String 

Command  ID 

1 

Integer 

X Hook  Position 

2 

Integer 

Y Hook  Position 

New  Minor  Cycle 

0 

Bit  String 

Command  ID 

Controller  Status 

o 

Bit  String 

Command  ID 

Destroy  Fix 

0 

Bit  String 

Command  ID 

1 

Integer 

X Hook  Position 

2 

Integer 

Y Hook  Position 

Destroy  FTP 

0 

Bit  String 

Command  ID 

1 

Integer 

X Hook  Position 

2 

Integer 

Y Hook  Position 
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TABLE  6-4.  NODE  70  ASYNCHRONOUS  OUTPUTS 
(XMT  SUB  ADR  30) 


COMMAND 

WORD 

NO. 

FORMAT 

TYPE 

CONTENT 

Contact  Alert 

0 

Bit  String 

Identifier 

1 

Bit  String 

Fix  1 ID 

2 

Bit  String 

Fix  2 ID 

3 

Bit  String 

Fix  3 ID 

4,5 

Floating  Point 

Target  Latitude,  deg. 

6,7 

Floating  Point 

Target  Longitude,  deg. 

3,9 

Floating  Point 

U Target  Grid  Coordinates,  nm 

10,11 

Floating  Point 

V Target  Grid  Coordinates,  nm 

12 

Scaled 

Target  Bearing,  deg. 

13 

Scaled 

Target  Velocity,  knots 

Bit  String 

Target  Classification 

Bit  String 

Target  Display  Cue 

6.6. 1.3.2  Operational  Modules.  These  modules  deal  with  the  operational  as- 

pects of  the  scenario.  Thev  perform  position  calculations,  format  outputs, 
manage  the  fix  and  track  files,  respond  to  commands,  and  write  messages  to 
the  bus.  Figures  6-9  through  6-29  describe  these  operational  functions.  These 
modules  operate  primarily  on  three  data  files:  the  track  file,  the  fix  file,  and 
the  sonobuoy  files.  The  contents  of  a typical  entry  for  each  file  are  shown  in 
Figure  6-2.  The  number  of  entries  in  each  file  is  contained  in  the  variables 
NUM TRAC  KS , NUM_FIXES,  and  NUM_SO  NO  BUOYS. 

6.6. 1.3.3  Test  and  Reconfiguration  Modules.  Node  70  executes  a self-test 
program  every  minor  cycle  and  reports  the  result  to  Node  90  by  means  of  a self- 
test output  message,  as  described  in  Table  6-7.  Node  70  also  receives  the  Node 
90  self-test  output  and  returns  it  to  Node  30  on  request.  This  occurs  if  Node  30 
has  received  a self-test  message  from  Node  90  indicating  a Node  90  failure  and 
is  for  verification.  Figures  6-24  and  6-25  describe  the  test  and  recovery 
function. 
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TABLE  6-5.  NODE  70  INPUT  MESSAGE  FORMATS 


SOURCE 

NODE 

XMT 

SUB 

ADR 

RCV 

SUB 

ADR 

TYPE 

FORMAT 

TYPE 

WORD 

NO. 

CONTENT 

1 

Message  ID 

21 

2 

2 

Static 

Integer 

2,3 

.Aircraft  Latitude 

(JTIDS) 

Floating  Point 

4,5 

Aircraft  Longitude 

Floating  Point 

6,7 

CMD  Altitude 

Floating  Point 

9,9 

Grid  Azimuth 

Floating  Point 

10,11 

CMD  HDG 

Floating  Point 

12,13 

CMD  Course 

Floating  Point 

14, 15 

TACAN  Range 

Floating  Point 

16, 17 

TACAN  BRG 

Floating  Point 

18, 19 

Time  of  Day 

Bit  String 

20 

TACAN  JTIDS  Mode/ Status 

Floating  Point 

21,22 

Runway  HDG 

Floating  Point 

23,24 

Glide  Slope  Error 

Floating  Point 

25,26 

Lateral  (Localizer)  Error 

Bit  String 

27 

Landing  Alerts 

Floating  Point 

28,29 

Ref.  Latitude 

Floating  Point 

30,31 

Ref.  Longitude 

Bit  String 

32 

Waypoint  ID 

3-7 

3-7 

Static 

Bit  String 

1,17 

Track  ID 

Bit  String 

2,18 

Fix  1 ID 

Bit  String 

3, 19 

Fix  2 ID 

Bit  String 

4,20 

Fix  3 ID 

Floating  Point 

5,6,21,22 

Latitude 

Floating  Point 

7,8,23,24 

Longitude 

Floating  Point 

9, 10,25,26 

Grid  Coordinate  (U) 

Floating  Point 

11, 12,27,28 

Grid  Coordinate  (V) 

Scaled 

13,29 

Bearing 

Scaled 

14,30 

Velocity 

Bit  String 

15,31 

Classification 

Bit  String 

16,32 

Display  Cue 

106 

1 

8 

Static 

Bit  String 

1-12 

Preset  Pattern 

107 

1 

9 

Static 

Bit  String 

1-24 

Preset  Pattern 

110 

1 

10 

Static 

Bit  String 

1-2 

Preset  Pattern 

112 

1 

11 

Static 

Bit  String 

1-4 

Preset  Pattern 

113 

1 

12 

Static 

Bit  String 

1-12 

Preset  Pattern 

114 

1 

13 

Static 

Bit  String 

1-8 

Preset  Pattern 

I 
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NODE  70  OUTPUT’  MESSAGE  FORMATS 


FORMAT  TYPE 


BIT  STRING 
FLOATING  FT 


INTEGER 
FLOATING  FT 
FLOATING  FT 
INTEGER 
SCALED  INTEGER 


FLOATING  POINT 


i SCALEO 
SCALE 0 
BIT  STRING 
BIT  STRING 


BIT  STRING 
FLOATING  FT 


INTEGER 
FLOATING  FT 
FLOATING  FT 
INTEGER 
SCALEO INTEGER 


MB 

1.  It 
4.5: 20.21 
1,7  2223 
1.9:  2425 
10.11  26.27 
12. 20 

13  29 

14  30 
15.  31 


CONTENTS 


GROUP  10 

LATITUDE  OF  A/C  (OEGI 
LONGITUDE  OF  A/C  (DEG) 

GRIO  CO-ORO(U)  MILES 
GRIO  CO  ORO  (VI  MILES 
BARO  ALTITUDE  FT. 

RADAR  ALT  FT 
COMMANO  ALT  FT 
COMMANO  ALT  ERROR  FT 
GROUND  SPEED  FT/SEC 
TRUE  AIR  SFEEO  FT/SEC 
INDICATED  AIR  SFEEO  FT/SEC 
COMMANO  AIR  SPEED  FT/SEC 
COMMANO  AIR  SFEEO  ERROR  FT/SEC 
MACH  NO. 


TRAC.*  ID 
FIX  1 10 
FIX  2 10 
FIX  310 
TGT  LATITUDE 
TGT  LONGITUOE 
TGT  GRIO  CO  ORO  IUI 
TGT  GRIO  CO  ORO  (VI 
TGT  BEARING 
TGT  VELOCITY 
TGT  CLASSIFICATION 
DISPLAY  CUE 


GROUP  10 

LATITUDE  OF  A/C  (OEGI 

LONGITUOE  OF  A/C  (OEGI 

GRIO  CO-ORD  IUI  MILES 

GRID  CO  ORO  (VI  MILES 

BARO  ALTITUOE  FT 

RAOAR  ALT  FT 

COMMANO  ALT  FT 

COMMANO  ALT  ERROR  FT 

GROUNO  SFEEO  FT/SEC 

TRUE  AIR  SPEED  FT/SEC 

INDICATED  AIR  SFEEO  FT/SEC 

COMMAND  AIR  SFEEO  FT/SEC 

COMMANO  AIR  SFEEO  ERROR  FT/SEC 

MACH  NO. 


„ 

OVNAMIC 

BIT  STRING 

8.  IB 

TRACK  10 

a 

1.  17 

FIX  1 10 

2.  11 

FIX  2 ID 

3. 19 

FIX  3 ID 

FLOATING  POINT 

4.5:2021 

TGT  LATITUDE 

DEG 

9.7  : 2223 

TGT  LONGITUOE 

DEG 

t.t:  2425 

TGT  GRIO  CO-ORD  IUI 

MILES 

1 

18.11: 2827 

TGT  GRID  CO  ORO  IVI 

MILES 

SCALEO 

12, 28 

TGT  BEARING 

DEG 

SCALEO 

13.29 

TGT  VELOCITY 

KNOTS 

BIT  STRING 

14.38 

TGT  CLASSIFICATION 

BIT  STRING 

It.  31 

OISFLAY  CUE 
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TABLE  6-6.  NODE  70  OUTPUT  MESSAGE  FORMATS  (Continued) 


XMT 

RCV 

DEST 

SUB 

SUB 

WORD 

- 

NOOE(S) 

ADR 

ADR 

TYPE 

FORMAT  TYPE 

CONTENTS 

GROUP  10 
MAG  HOG 
GRID  AZIMUTH 
CMO  HOG 
CMO  HOG  ERR. 

CMO  COURSE 
CMO  COURSE  ERR 
WIND  SPO 
WIND  BEARING 
ANGIE  OF  ATTACK 
SLIP  INOICATOR 
BEARING  TO  OEST 
RANGE  TO  OEST 
TACAN  RANGE 
TACAN  BEARING 
TACAN  DEVIATION 
TIME  OF  OAY 
TIME  TO  GO 


GROUP  10 
CONTACT  10 
FIX  10 

TGT  LATITUDE 
TGT  LONGITUDE 
TGT  GRIO  CO  ORO  IUI 
TGT  GRID  CO  ORD  (V) 
CLASSIFICATION 
OISPLAY  CUE 
TIME  OF  FIX 


GROUP  10  (SONOBOUY  101 

SONOBOUY  GRIO  CO-ORO  IU.VI 

N.M. 

VECTOR  ENO  POINTS  (U.VI 

N.M. 

DISPLAY  CUE 

NJM. 

NOOE  10.  MAJOR  CYC.  =.  MINOR  CYCLE 

S 

STATUS  WORO  1 

STATUS  WORO  2 

SYSTEM  CONFIGURATION  10 

SELF  TEST  RESULTS  WORO 

OLO  SEQUENCE  WORO  (LAST  WORO  7 SENT) 

TBO 

NEW  SEQUENCE  WORO 

NADC-79161-40 


Figures  6-3  through  6-8.  Node  70  Executive  Functions 
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MOOULE  NAMEJ  INITIALIZE  NA V SYSTEM 


DATA  REQUIRED 


NONE 


DATA  PRODUCED 


HONE 

INITIALIZE  NAY  SYSTEM 

th IS  PROCESS  IS  ACTUATED  OY  A RO«£R  cn  CONOITIDN 
(IF  POSSIBLE).  IT  LOADS  PROGRAMS  AMP  “RESET  DATA 
FROM  THE  FL  C°°Y  n I S Y AMO  SETS  ANn  NECESSARY  INITIAL 
VALUES.  IT  ALSO  INITIALIZES  THE  INTERRUPT  STRUCTURE 
AND  SCHEDULES  THE  ••OUTPUT  PROCESSING"  AND  "SELF  TEST" 

FE  RIOOIC  MOOULES.  FINALLY.  IT  CALLS  THE  "DISPATCH”  NODULE 
TO  INITIATE  RRCCPSSING. 

ENO 


Figure  6-3 


MODULE  NAME  t INTERRUPT  HANDLER 


DATA  REQUIRED 


type  OF  E'/EN»  ( E t r NAL  op  aus  IN=uTt 


OATA  PROOUCED 


NONE 

INTERRUPT  HANDLER 

THIS  FUNCTION  SAVES  THE  STATE  OF  ’Hf  MACHINE  AMO  TRANSFERS 
CONTROL  TD  THE  RRQPE’  INT c RRUPT  PESPONSE  MODULE 


LOST  OUT  ALL  flRthcc  INTERRUPTS 
SAVE  RRpp.RAM  ctr 
S«VP  STACY  POINTERS 
SA vc  REGISTER  CONTENTS 

CASE  INTERRUPT  TYPE  (EYTE“NAL  Op  SUS  INPUT) 
. “EYTFRNAL  INTERRUPT" 

. -REAO" 

ENOCASE 

FESTDRE  machine  STATE 
enable  INTERRUPT* 

TRANSEFF  TO  RRCO.RAH  CTC 
ENO 


Figure  6-4 
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M00UIE  NAME  t 0 ISP ATCH 


OATA  REQUIRED 


INIT  (INITIAL!.* 

Ncw_"I‘IOp_C'QLE.clAr, 
PERIODIC  *RCr»PAM  PARAMETERS 
-STACk.poi ntpr 

• OF ° T M_  0 f STACK 


P&ESFT  TO  oi 


OAfA  PROOUCFO 


‘10  It 


DISPATCH 

Tuts  £>cnc-3S  OALlS  ALL  tmc  pe^I^CIC 
c*?CUTtO  0*  fH(  7 - ? , rT  T S THE  LOWEST  PPIORITV 
csn^c^S  a 'JO  TS  ne  €• FMOT  EO  «v  ALL  I vi  T c*  dpijd  TS  , 
jt  os PgATS  r0R  “ACM  M I NCR  C VCLC • °£cioniC  PPOCFSS 
API  PRIORI*  ITEC  TWEIP  POSITION  IN'  T«E  STACK. 


00WHIL6  IS  0‘l 

IP  *Jt'^_HlNOc_r*CLE.cLAr»  FT  l AnO  IMIT_FLAG  EC  1 

THEN 

S £ T ‘IP  J.^I'lOP.ry^LE^PLAG  TO  <] 

3QWMILE  STICK  MOT  ‘MPTy 

. IN  IT  I5L  1 7E  MACHINE  STATp  ^C-5  r AC  H PEPirrir  PROCESS. 
. EAC'-<  SMCK  f.  M T K V POINTS  TO  A OijFrro  ACgA  CONTAINING 
. INITIALISATION  pap ft -^rr or, 

. CALL  ppoC£S-  ^fp^rE'.’T  r0  ov  STAC*'  Entry. 

EN000 
ENOIF 
FN000 

FNO 


Figure  6-5 
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MOOULE  NAMEi  read 


DAT*  REQUIRED 


tmpijx  *x-  SSAGT  (ASSIJMEO  TO  BE  LOCATED  IN  I.".  BUFFER) 
r,(iLr  OF  )RfORT  p')FFEc  LOCATIONS  FO®  EACH  FCV  AOPESS. 
FABLE  OF  DUFrro  LENGTHS  c0R  EACH  FCV  ADDRESS • 

INPUT  MFSSAGE  RCV  aopffss 


OAT A PROOUCED 


INPUT  MESSAGE  in  FCV  AORESS  PUFFER 


This  MODULE  = EA1S  Tw£  input  MESSAGE  FF"H  The  INTERFACE 
MODULE.  ONL  T A fmnCHFONOUS  COMMANDS  *®E  ACTUALLC  SAVFp. 
ALL  HMDS  MFSSAGFS  AFE  ACKNOWLEDGED  nUT  NOT  SAVEr. 


F£  AD  FCV  A0r3ESS 
IF  f^v  ao°ESS  ES  TO 

. INPUT  1 WORDS  TO  FD'.'  AODPESS  to  INPUT  message  P'lFFEF 
. ACKNOWLEDGE  INPUT 
• 'SL'w  "'Og  UNI  P-nr£T  r * NC” 

. €LS£ 

. a c<‘icwLr  nr,r  i*ip»jt 

ENOI  r 


Figure  6-6 


MOOULE  NAME1  WRITE 


DAT*  REQUIRED 


»MT  "rSSAGF  A n DR®  S S 

T fl^Lr  OF  OUFrro  LOCATIONS  r0P  FACH  X ••  I AOPFFSS 
TAIL®  OF  oijfFFo  LENGTHS  fop  EA"m  «mT  ACTRESS 


0 A T A PROOUCED 


OUTPUT  MfSSAGF  TO  INTERFACE  M00ULr 


'His  FUNCTION  OUTPUTS  THf  SPECIFIED  MESSAGE 
TO  THE  I NT  f cf  AQr  MODULE.  IT  WAITS  c0®  AN  ACKNOWL  EDGE 
FQ’  A SPFCIFIFO  °ERIDO  OF  T I ME . NONE  OrPIlRING.  AN 
E=p"R  CONDITIO*  IS  NOTEq  IN  T»E  STATUS  WORD. 


Figure  6-7 
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' 77 


MODULE  NAME  I CCMANO  PROCESSING 


DAT*  REQUIRED 


IMO'IT  MEScaGE  (RCV  AORESS  T 0 » 
-COMMAND  MORO 
.»  MOOR  °OS IT I ON 
-T  HOOK  POSITION 


DATA  PROOUCED 


NONE 


COMMANO  PROCESS 

TMIE  m.ooijl"  I‘ITr:B-ETS  T“E  comment!  jo  ANp  OAl'T 
fM£  AooEOosj.rc  Syppoi/T  TVS  TO  -:r-r( jjc  rHr  COMMAND. 

r . -r  <*  • u r<  » •* 

. ' : I ■ ■ ;r 

, STPRMINATc  1 1 m 

. »<ar<  riN-t 

. ';l|T-c  cj*t 

. ,')S~>T- 01  ci<t 

, * - n t r c Fiji 

. rO£ST['OT  rjnt 
, ’F("  ENTE=  (_  A T 

. *• CENTER  LONG 

. r ACKNORL  EOGr  CONTACT* 

. 0EST=0*  CONTACT 

. o=>OP  SONOPOLT 
. CONTSPLLE3  STATUS 
. *NEM  minor  CTCLrt 
ENOCASE 

END 


Figure  6-8 
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N£  4 VIN0P  CYCLE 

$"f  VP W_*IVO'»_C*'*LF.ELiG  TD  1 

EVO 


Figure  6-9 


INITIALIZE  MV 

'ir  vav. K4i r. pug  Tn  i 
EVO 


Figure  6-10 


TEPHVATE  HT 

**-  T MV.  IN  IT. PUG  I'n  ’ 
EVO 


Figure  6-11 


MAP*  TIME 

t m j ^ *4on»H.“  !M!T’AiI7E*>  ttmc  Tn  n 
AM 0 STARTS  r:M£."P.0Av  rO'lMTE® 

S:T  TI^“.0r  1 A * _ * CUN  T ► o TO  0 

'TAPT  T T _ 0r  _ 'M*  nn>,Ttr  ? 

ENO 

Figure  6-12 
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PMfl 


MOOUlE  NAME*  ENTER  FTP 


DATA  REQUIRED 


nr, 0#  POSITIONS 
rTP  STAC* 

POINTERS,  IKDICES,  STA^K  °ARAmEtE®^ 


0AT1  PROOUC  ED 


N£W  cro  STAOK  ENTCr 
ENTER  PT p 

T«:f  wnnilLE  ADCS  An  £NT=>v  to  Twr  cto  ^TAPW' 
CONV-CT  *,*  M00<  PCSITICN  TP  If,  'f  pp^n  PQ-ORP 
T'»Sf-r  r.  = Z0  C 0-^  = 0 at  tqp  or  rrr  r T AC  *< 

IMP5  E :T$MT  M1IM_F*C 


Figure  6-13 


NOHIILE  NAHEI  0EST90Y  CTP 


DATE  REQUIRED 


r,r  ‘<oa«  POETTCN 
ctp  pra^K 
L AS  r _c  TP 
r j ^sT  rTo 


0»T»  PPOOUCEO 


MTDIPI£n  rT®  ^TSC1' 


DESTROY  FTP 

tm[f  MODULE  pfpi }VE"  Thf  r.PECIrTcO  ENT®*  cans  ’me  ftp  FT6CF 

SFT  ftp.IMHF*  TO  l 
SET  FIMO.FL*'"-  M (I 

00  WHILE  Fino.Fur  EO  x auo  fto_ihoex  lE  NUM.FTO 
. IF  X.t  "OSITirN  OF  H00<  "TLOSE  ENOUGH"  TO  ft  d tc  ro_  X J.J0E  xt 

. . THEM 

. • OELEIP  ENTs v a v|0  SHOoTEN  FUCK 

. . S*  T FIN0.FE4F.  TO  1 

. EMOIF 

. INCREMENT  SIO^INOEN 
ENOOO 

EMO 


Figure  6-14 
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, , ...  . ... 


M00ULE  NAME I ENTER  FIX 


OAT*  REQUIRED 


y.t  hook  position 

'■IX  FILE 

T R A C K F I L£ 

POINTFPS,  I AO  ICE'S,  file  pARAmETfos 


OATA  PRODUCE!) 

MEN  FIX  FILr  E NTF  V 


ENTER  FIX 

THIS  MODUL-  ADC"  AN  ENT  RX  TO  THE  CI»  file 

AOF'NO  E“°TV  file  fntry  *0  FIX  r ILE 
A°°fnd  a ”I~  tc  hem. FIX. Flat,  VECTOR 
SET  "RACK  INDEX  t 0 T 
SET  FIND. FLAG  TO  0 

OOMHILE  t’ACK.  INDEX  LE  NU*x. TRAC *S  AND  FIND.Fi.Ar,  ~r)  n 
. CONVE'T  <.Y  H^DX  ODS  To’ll.V  GRID  "0-Cc"I  NATES 
. IF  U,  V CC-0«n  of  HOOK  "CLOSE  ENDLC.H"  TO  IJ.V  rr=0PD 
. . OF  TRACK (TRACK. INDfx» 

. . THEN 

. . SET  CONTACT  IO<LAST.rix»lt  TO  CONTACT  ID  ( T = A<-<_  inqf X 1 

. . SET  FIND. pi,  AC  "D  l 

. ENOIF 

. I NO  - E *'E  N T TRACK. INDEX 
ENOOD 

FDRHJT  >|£H  fix. ID  AND  cnTE  = 

(flat  earth  apprcx) 

IF  find. FLAG  EO  1 

. then 

, TRANSFER  la  VLDNC  ANO  GRID  CO-CRO  OF  T RACK  (T  PACK  INDEX) 

. TO  FIX  file 

. SET  contact  10  TD  TRACK  ID  ( T P AC K. r NOF X) 

. SET  CLASSIFICATION  TO  "TAFCET  fix"  INDICATION 
. ELSE 

. CONVERT  HDDK  POSITION  TO  U/V/LAT/LONG  CO-OPD 
. r n TE P U.V  AND  LAT/LONC  rn-ORDINA T£S  IN  Fix  FILE 
. SET  CLASSIFICATION  TO  "FIX” 

ENOIF 

F"T  DIS3LAV  CUE  TD  CLASSIFICATION  INDICATION 
ENO 


Figure  6-15 
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THIS  MODULE  AOCS  ANOTHE  = PNTP»  TO  tmc  SCM08 OUT  FILE, 
r.  I V I M 0 Thc  SCNCOOUT  the  PRESENT  POSITION  OF  the  Arc 

FORMAT  N^w  SONCOOUY  10  AMO  ENTE°  IN  SONCPOUY  FILE 
TOANSFER  Mil  S0-O»OINAT£S  OF  own  4FC  TO  FILE 
EE  T DISPLAY  CUE  OF  NEW  ENTRY  TO  INDICATE  S0N0POUY 
SET  APponpoUTE  COMPONENT  OF  NE  W.SONO.r  L AO  TO  1 
IN CPE  ME NT  NUM. TONOOOUYS 

ENO 


Figure  6-16 


acknowledge  contact 

THIS  CILE  SEA®CHES  the  SONOOOUy  ttlE  TO 
CETER-INF  UMICV  CONTACT  IS  'E  INC.  AC  ymq  wL  EOGEO 

SET  SONO.INOEY  TO  1 
SCT  rINO_rLAG  TO  0 

00 WHILE  c0N0_  INOEY  l£  MI)m.SONOPOO»S  ANT  <TIP.FL«fi  t"  1 
. IF  OIS°LAY  CUff  OF  SONOOOUY (SONO. !NOeXl  £0  "CGNTACT" 

. . IF  Y.Y  POSITION  OF  HOOK  "CLOSE  ENOUGH"  TO  SONCPOUY  POSITION 

. . . SrT  0 1 S r L A v SUE  OF  pondoouy • SONO. ! MCE y I T0  OA 0 KNCWL rOGF 0 

. . . CONTACT;) 

. . . SET  A°P=CPPIATE  N£  w. SONO.r  L AG  COMPONENT  TO  1 

. . . SET  FINO.FLAG  TO  1 

. . ENOIF 

. ENOIF 

. I NCRE  nr  N T SONO.INOEY 

ENOOO 

ENO 


Figure  6-17 


DESTROY  CONTACT 

THIS  NODULE  RE “OV  ES  * H"  "ACKmOWLcCOE  CONTACT" 

r£Sir.NAT  TON  r»CM  THr  APPROPRIATE  SONOTTOI'T  £NTC»  IN  Tw£  SONOnOUY  FILE 

SET  SONO.INC-Y  TO  1 
SET  FI  NO.  FLAG  10  0 

OOWMILE  SONO.  I NOE  x LF  NUH.SONOOOUTS  ANO  PINO. flag  eo  0 
. IF  »,Y  HOOK  POSITION  “CLOFE  enough-  TO  SONOROUY  TFONO.  Imoe  *) 

. . SET  OIS°tAY  CUE  or  SONOPOUV*S  CNO.  T NOE  X I T0  -SONOOOUY"  DESIGNATION 
. . SET  APPROPRIATE  NEW. SONO. FLAG  COMPONENT  TO  1 
. . SET  F I NO.rL  AG  to  1 

. ENOIF 

. INCREMENT  SCNO.INOE* 

ENOOO 

ENO 


Figure  6-18 
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OATA  REQUIRED 


S0NOB0UY  PILE 

-sonorduy  ir 
-u  OP  10  C0-0=D 
-V  OR  TO  CO- CRD 
-DISPLAY  CUE 
-»  OIS“L»Y  CO=ORD 
-Y  DISPLAY  so- PRO 
-TI ME. DP .UP CATE 
-VECTOR  END  PQ  INT  ( X I 
.VECTOR  FRO  PO I KT  (Y» 
TRACK  PILE 

POINTERS.  IAOICES.  ETC 


DAT*  PROOUCEO 


MODIFIED  SONODOUY  PILE 


CONTACT  UPOATE 

thtj  MODULE  EYECUTES  OCRIOOIC3LLV  prcoy  rr  SECONCS 

ANO  DETERMINES  mn£Tucr  A MOVING  tjoq^t  00  JECT  TN  THE  'PACK 

FILE  IS  "CLOSE  ENOUGH"  TO  3c  OETPC'cD  "•»  A SIMULATE"1  SONOROii 

SET  T RA~k. I NOE » TO  1 

SET  SOnp.INOEY  TO  t 

DOWHILE  TRACK. INOEY  LE  MUM.  TRACK" 

. OONHILE  SON  t.  I NOE  y lE  MUM.sONnnouvS 

. . IP  SOKOPCUY  fSONO.  INOEY)  •TL''JE  ENCUGH"  T"  TARGFT(TRA"K 

. . . THEN 

. . . sr  r 0 I T c L A * CUE  TO  "CONTACT"  OESIGNATIOA 

. . . ELSE 

. . . SET  0 I > f L A Y CUF  TO  "SONOOOUY"  DESIGNATE  ON 

. . ENOIF 

. . SFT  T THE. Oc .CONTACT  TO  PRESENT  TI-E 

. . IP  SONODOUy  tSONO.INOFX)  INDICATES  0 IP  A R TO  AND  OIS  = LAy 

. . . INOICATES  "CONTACT" 

. . . then 

. . . CALCULATE  vector 

. . . ENO 

. . . POINTS  ANO  ENTER  IN  FILE 

. . . ELSE 

. . . SFT  VEC'OP 

• • • 

. . . ENO 

. . . POINTS  TO  0 

. . ENOIF 

. . TNCRE  MrN  T SONO.INOFY 
. ENOOO 

. incoenent  TPACK.INOC* 

ENOOO 

SET  CONTACT.  U°CA  T E FLAG  TO  t 

SET  ALL  COMPONENTS  OF  NEW. SONO. FLAG  TO  l 

ENO 


Figure  6-19 
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MOOULE  NAME  I OISTROV  FIX 


OAT*  REQUIRED 


FIX  FILE 

MO OK  POSITION 

»TRS.  INDICES . FILE  PARAMETERS 


DATA  PROOUCEO 


U»OATEO  FIX  FILE 

oestrot  Fix 

SFT  FINO.FLAG  10  0 
SET  I TO  1 

OOWMILE  I LE  NUN.  FIXES  »N0  FINO.FLAG  EO  n 
. IF  M00K  "CLCSE  enough”  TO  Fix  POSITION 
. . REMOVE  E>T3X  from  fix  file 
. . REMOVE  COMPONENT  FPOM  NEW.FIX.FLAG 
. . SET  FINO.FLAG  TO  1 

. ENOIF 

. INCREMENT  I 
ENOOO 

ENO 


Figure  6-20 


RECENTER  LAT 

SET  CENTER. OF, OISPLAX  LATITUDE  COMPONENT  TO  DATA  WORDS 
END 


Figure  6-21 


PECENTER  LONG 

SET  CENTir.of.DISPlAX  LONGITUDE  COMPONENT  TO  DATA  WOPOS 
END 


Figure  6-22 
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NOOULE  NANE  NAD  OUTPUT  PROCESSING 


DATA  REQUIRED 


Ohm  A/C  PARA-ctfp  BUFFER 
-L  ATI  TtjOE  ( 3 < “ITS-OYNANIC) 

-LONGITUDE  (3E  pITS-O^NANIC) 

-U  OR  ID  CO-CRC  ( 3?  BITS, DYNAMIC) 

-Y  GRID  CO-OP 0 (OYNANIC-3?  SITS) 

_SARO  alt  (STATIC) 

-PAOAR  ALT  (STATIC! 

-CONNANO  ALT  (STATIC) 

-GROUND  SPEEO(STATIC) 

-TRUE  AIR  SPEC  0 (STATIC) 

-IN0ICATE3  AI0S®EED  (STATIC) 

-CONNANO  AISS*EEO  (STATIC) 

-CONNANO  A IPS®  EEO  ERROR  (STATIC) 

-NACM  NO  (STATIC) 

-RANGE  TO  DESTINATION  IOYNANIC-3?  PITS) 
-TINE  TO  GO  (OYNAHIC-T?  PITSI 
-ACCELERATION  (0YNANIC-t6  PITS) 

-TELOCITY  (OYNANIC-16  PITS) 

-READING  (OYNANIC- IP  “ITS) 

TRACK  PILE 

P I Y pile 

SONOPOUV  PILE 

POINTERS.  I (DICES.  rILr  PARAMETERS.  FLAGS. 


.. 


ETC 


OATA  PROOUCEO 


U»DATE  OF  OUTPUT  MESSAGE  pijFPERS 
-0UF,6  (XNT  SUB  A OOR ESS  P - IS  WORDS) 
-PUF.n  (ID  WOROS) 

-PUF_T,BUP_T.»UF_tl  (?1  WORDS) 

-PUF.u,  BUF.1F  (3?  WOPOS) 

-9IJF.1?  (?1  WORDS) 

-PUF.1J,  PUF.IL,  9UF_15  (30  WORDS) 
-PUF.U  (?(.  WDROS) 


Figure  6-23a 
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NAV  OUTPUT  PROCESSING 

this  MoouLf  Executes  ever*  minor  cycle  ano  updates 
the  OUTPUT  BUFFERS  for  TRANSMISSION  TO  OTHER  mopes 

BLOC*  1-  PROCESS  0HN  A/C  POSITION 
IF  ftp. FLAG  EO  1 
. THEN 

. UPDATE  LAT/LONG/tl/V  CO-ORO  USING  CONSTANT  INCREMENTS 
. CN TER  NEW  CO-OROINATES  IN  OHN  A/C  PARAMETER  BUFFER 
. ELSE 

. UPOATr  LAT/LONG/U/V  CP-OPO  USING  CIRCULAR  APPROXIMATION 

. ENTER  N£H  CC-ORO  IN  OWN  A/C  PARAMETER  BUFFER 

ENOIF 

ENTE®  NEW  CO-ORO  I K BUF_3,0UF_7,  ANP  BUF.ll 
BLOCK  ?-  PROCESS  OHN  A/C  VELOCITY  ANO  HEAOING 

if  ftp. flag  eo  t 

. THEN 

. UPQATE  "RANGE  TO  PEST  I NATION"  AMP  "TIME  TO  GO"  paRAMFTfos 
. ENTER  PARAMETERS  IN  CHN  A/C  BUFFER 
. ENTER  PARAMETERS  IN  BUF.12 
. ELSE 

. IIRQATE  ACCELERATION,  VELOCITY,  AMO  HEADING  PARAMETERS 

. ENTER  PARAMETERS  IN  OWN  A/C  BUFFER 
. ENTER  PARAMETERS  IN  0IJF.6  ANO  OtJF.lo 
ENOIF 

BLOCK  I-  °R  OCE  IS  FTP_STACK 
IF  FTP. FLAG  EO  t 

. IF  POSITION  Oc  OHN  A/C  "CLOSE  ENOUGH"  TO  TOP  STACK  ENTRY 

. . THEN 

. . REMOVE  T0“  ENTRY  FROM  STACK 

. . DErRE“ENT  nijm.ftp 

. . IF  NUH.FTP  COO 

. . . THEN 

. . . SET  FTP. FLAG  TO  0 

. . ENOIF 

. ENOIF 
ENOIF 

BLOCK  W-  PROCESS  TRACK  FILE 

SET  TRACK. INOEY  TO  1 

OOHHTLE  TRACK.  INCEY  LE  NUN. TRACKS 

. INCREMENT  LAT/LONG/U/V  CO-ORO  OF  TAPGF  TS  USING  CONSTANT  INCREMENTS 
. IF  ALL  THREE  FIX  TO  PARAMETERS  ARE  NCN-TERO 
. . THEN 

. . SET  APPROPRIATE  COMPONENT  OF  NE  H.  To  ACK.FL  AG  TO  t 

. ENOIF 

. INCREMENT  TJACK.INOEX 
ENOOO 

SET  OICRLAY  CUES  IN  BUF.U  ANO  BUF.1B  TO  0 
SET  I TO  1 

SET  J TO  1 

OOMHILE  I LE  NUN.  TRACKS  ANO  J LE  ’ 

. IF  NEW. TRAC*. FLAGC  II  F0  1 
. . SET  NEW. TRACK. FLAGYI)  t0  0 

. . COPY  oarAMETfrs  INTO  APPROPRIATE  HALF  CF  BL'F.U  ANO  PUF.tB 

. . INCREMENT  J 

. ENOIF 
, INCREMENT  I 


Figure  6-23b 
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ENOOO 

slocx  5-  process  pi*  file 

CE  T OISPLAT  CUES  in  “UE.IT,  HUE. Ik,  9UF.1S  TO  3 
SET  I TO  i 
EE  T J TO  t 

DOMHILE  J IE  S UNO  I (.E  MU1.FIXES 
. IE  Nt  W_F  Ix_  *L  A G 1 1 > EO  1 

. . St'  NE*_EIX_ELAr,(  I)  TO  1 

. • COPT  E I X ENTPXIH  INTO  APPROPRIATE  SUFFER  AREA  ITNDEX  or  J) 

. . INCREMENT  J 

. ENOIE 
. increment  I 
ENOOO 

PLOC*  r-  PROCESS  S0N090UT  FILE 
SET  0ISPC9T  CUES  IN  9UF_  1 7 to  rj 
IE  CONTACT. UP04TP  rtflG  EO  l 
. SET  I TO  i 
. SET  J TO  l 

. OOMMILE  I LE  NUM.SONC"0IJVS  ANO  J LE  ’ 

. . IE  ME  W_SCN0_E(.AG(  It  EO  1 

. . . SET  NEN.SONO.ELBGTII  TO  3 

. . . COP»  S0N0O0IJV  ENTRTin  TNTC  APPROPRIATE  HSLE  of  miFEEO 

. . . INCREMENT  J 

. . ENOIE 

. . INCREMENT  I 

. ENOOO 

ENOIE 

"LOC<  7-  OUTPUT  SUFFERS 
EE T I T0  1 

OOWHILE  I LE  NLMOER  OF  OUTPUT  RUFEfbr 
. MRITE  I" TH  SUFFER  TO  INTERFACE  MODULE 
ENOOO 

END 


Figure  6-23c 
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TABLE  6-7.  SELF-TEST  MESSAGE  FORMAT 


WORD 
(16  bits) 

CONTENTS 

1 

Node  ID,  Major  Cycle  No. , Minor  Cycle  No. 

2 

Status  Register  1 

3 

Status  Register  2 

4 

System  Configuration  Identifier 

5 

IFPM  Test  Result  Word 

6 

Old  Sequence  Word  (last  word  8 sent  to  Node  90) 

7 

Return  Word  (last  word  8 received  from  Node  90) 

8 

New  Sequence  Word 

6.6.2  Node  82 

6.6.2. 1 General  Description 

This  node  formats  all  operator  inputs  (Keyset  depressions)  and  manages 
the  tactical  and  situational  advisory  displays.  For  the  purposes  of  the  imple- 
mentation subset.  Node  82  will  perform  a selected  number  of  the  navigation 
operator  functions,  the  steering  operator  functions,  the  display  operator  func- 
tions, and  the  MAD  operator  functions.  These  functions  are  activated  by  a Key- 
set depression;  they  either  accept  alphanumeric  data  from  the  operator  or  pre- 
sent a graphical  tableau  of  the  tactical  situation.  The  operator  may  also  position 
a "hook"  symbol  on  the  display  in  order  to  obtain  more  information  about  the 
"hooked”  item  or  to  enter  a command  regarding  it.  A list  of  the  selected  oper- 
ator commands  is  presented  in  Table  6-8. 
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Figures  6-24  and  6-25.  Node  70  Test  and  Recovery  Function 
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MOOULE  NAME  1 NAV  SELF  TEST 


04  TA  REQUIRED 


RESULTS  OF  SELF  test  PROGRAM 
7 STATUS  WORDS 

OLD  SEQUFNCF  WORD  ISEDUENCE  WORD  LAST  TRANSMITTED! 
LAST  RETURN  WORO  INPUT  PROM  NODE  90 


DATA  PROOUCEO 


0 WORD  SELF  TEST  MESSAGE  (B'IE_29A 
-NODE  ID,  MAJOR  CYCLE  NO,  MINOR  CYCLE  NO 
-STATUS  WORC  1 
-STATUS  MORC  » 

-CONFIGURATION  IOENT 
-RESULTS  of  SELF  TEST  P°OGRA  M 
-OLO  SEOUr MCE  MOPO 
-RETURN  WORC 
-NEW  SEOUENCE  WORD 

NAV  SELF  TEST 

TH IS  MOOULE  EXECUTES  EVERY  MINOP  CYCLE 

SET  WORD  S OF  »i|F_29  IQ  dcsijlT  OF  SELF  TEST  PROGRAM 
IF  FORD  5 INDICATES  A F A I LU°E 

. THEN 

. IF  FAILURE  RECOVERABLE 
. . THEN 

. . CALL  appropriate  PErni/ERY  ROUTINE 

, . SET  STATUS  WOODS  AND  CONFIGURATION  ID  TO  INDICATc.  NEW 

. . CONFIGURATION 

. . ELSE 

. , ATTEMPT  TO  ACTIVATE  SHUTDOWN  MECHANISM 

. ENOIF 
. ELSE 

. IF  NEW  MA  IOC  CYTLE 

. . im-pf went  major  cycle  no, 

. . SE T minor  TYCLE  no.  TO  0 

. ENOIF 

. SET  wn»0  1 CF  9IJF_I9  TO  NOOE  in,  “AJCR  CYCLE  NO,  “T NOR  mytlE  NO 

. increment  minor  cycle  no. 

. COPY  STATUS  WORO  I INTO  WORD  2 OF  B||F_  r>9 

. COPY  STATUS  WORO  2 INTO  WORD  S OF  BIJE_29 

. SET  WORO  *•  OF  9UF_P9  TO  CONF  IGU°AT  ION  ID 

. SET  WORO  6 OF  9UF_29  TO  LAST  WORO  A TRANSMITTED  FPOM  BUF.29 

. EET  WORO  7 CF  BUE_  29  TO  LAST  WDRC  A 'ECEIVEO  from  NOOE  90 

. SET  WORO  B OF  BUF.29  TO  A NEW  SERUENCE  WORD 
. wo  I TE  RUF.2?  TO  I.M. 

ENOIF 

ENO 


Figure  6-24 


CONTROLLER  STATUS 

TM  IS  MOOULE  RETURNS  T Mf  LAST  SELF  TEST  “ESSAGE  RECEIVED  FROM  NOPE  90 
IN  ’EspqnSE  to  a REQUEST  FROM  The  BACRUP/ MONITOR  FOR  NOOE  Rfl 

WRITE  last  SELF  TEST  MESSAGE  PECEIVFC  FROM  NOPF  90  70  IM 

ENO 


Figure  6-25. 
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TABLE  6-8.  NODE  82  COMMAND  INPUTS 


COMMAND 

FUNCTION 

Display  Init. 

Initializes  display;  North  UP  reference 

Configure 

Sets  configuration  for  SAD's  and  TAC/NAV 
display 

Alphanumeric 

All  text  and  text  control  characters 

Clear  Tactical  Plot 

Removes  fix  symbols,  reference  marks,  and 
DIFAR  vectors 

Acknowledge  Contact 

Indicates  acknowledged  contact  on  sonobuoy 

Reference  Mark 

Displays  reference  mark  at  hooked  position 

Clear  Text 

Clears  all  text  displayed  on  TAC  NAV  display 

Recenter 

Recenters  display  on  hook 

NAV  Init. 

Initializes  simulated  NAV  system 

Mark  Time 

Starts  system  clock 

Contact  Alert 

Displays  contact  symbol  at  sonobuoy  position 

Read  Latitude^  Longitude 

Displays  latitude  longitude  of  hooked  point 

Enter  Fly-to  Point 

Causes  simulated  aircraft  to  fly  to  hooked 
position 

Interrogate 

Displays  track  information  for  selected  target 

Enter  "ix 

Enters  fix  at  hooked  position 

Drop  Sonobuoy 

Displays  sonobuoy  at  own-aircraft  position 

Destroy  Fix 

Destroys  fix  at  hooked  position 

Destroy  FTP 

Destroys  FTP  at  hooked  position 

Terminate  NAV 

Terminates  navigation  program 

MAD  Reinit. 

Resets  MAD  subsystem  to  initial  condition 

MAD  Display 

Initiates  MAD  trace  with  annotation 

Activate  FRP 

Initiates  feature  recognition  processing 

MAD  Disable 

Terminates  MAD  processing 
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6. 6. 2. 2 I/O  Description 

The  input  and  output  messages  making  up  the  Node  32  interface  in  the  imple- 
mentation subset  are  shown  in  Tables  6-9  and  6-10,  respectively.  Asynchronous 
message  formats  are  dependent  upon  the  particular  command  they  represent  and 
are  described  by  the  particular  software  module  that  executes  them.  Formats 
and  data  content  for  the  messages  to  Node  82  are  shown  in  Table  6-11. 

6. 6. 2. 3 Software  Functional  Description 

6. 6. 2. 3.1  Control  Modules.  The  control  module  requirements  for  Node  32  are 
identical  to  those  of  Node  70.  Figures  6-26  through  6-31  describe  the  software 
executive  functions. 

6. 6. 2. 3. 2 Operational  Modes.  These  modules  format  data  for  display  and  out- 
put those  data  periodically  to  Node  31  for  display.  They  operate  on  the  files  shown 
in  Table  6-12.  These  files  contain  the  same  information  as  their  counterparts 

in  Node  70.  Figures  6-32  through  6-60  describe  the  operational  modules. 

6. 6. 2. 3.  3 Test  and  Reconfiguration  Modules.  Node  32  executes  a self-test 
program  evert-  minor  cycle  and  reports  the  results  to  Node  90  by  means  of  a 
self-test  output  message.  Figure  6-61  describes  this  module. 

6.6.2.  3.4  Node  32  Description.  Node  32  represents  the  operator  display  por- 
tion of  the  system.  This  node  receives  data  from  the  bus  and  displays  it  without 
modification.  It  receives  data  only  from  Node  31  according  to  the  message  for- 
mats specified  in  Table  6-11.  The  actual  implementation  of  Node  82  is  dependent 
on  the  display  hardware  available  and  is  presently  being  implemented  by  502. 
Formal  documentation  is  presently  unavailable.  For  this  reason.  Node  32  is 
not  further  described.  It  does,  however,  perform  the  same  self-test  function 
as  Node  31  every  minor  cycle  and  sends  the  resultant  message  to  Node  90. 
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TABLE  6-9.  NODE  82  INPUT  MESSAGES 


SRC 

NODE 

i 

RCV 

SUB 

ADR 

WORDS 

PER 

SECOND 

PE  RIOD 

IN 

MSEC 

Hi 

30 

6 

0 

30 

6 

400 

30 

7 

3600 

I 

8 

9 

10 

11 

12 

30 

30 

3 

0 

70 

16 

1240 

17 

13 

70 

19 

1500 

20 

21 

70 

22 

320 

1000 

70 

23 

100 

2000 

70 

30 

16 

0 

90 

30 

0 

108 

24 

8 

1000 

mm 

30 

3 

0 

124 

30 

40 

0 

125 

30 

40 

0 

126 

30 

40 

0 
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Figures  6-20  through  6-31.  Node  52  Executive  Functions 
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mooule  namei  initialize  display  system 


DATA  REQUIRED 


NONE 


DATA  PRODUCED 


NONE 


INITIALIZE  OISPLAY  SYSTEM 

THIS  PROCESS  IS  ACTUATED  BY  A POWER  ON  CONDITION 
(IF  POSSIBLE).  IT  LOADS  PROGRAMS  ANO  PRESET  OATA 

OISPLAY  SYSTEM  FROM  THE  BUS  ANO  SETS  THE  NECESSARY  INITIAL  VALUES 
VALUES.  IT  ALSO  INITIALIZES  THE  INTERRUPT  STRUCTURE 
AND  SCtlEOULES  THE  OUTPUT  PROCESSING  ANO  SELF  TEST  MODULES. 
FINALLY,  IT  CALLS  THE  "OISPATCH"  MODULE 
TO  INITIATE  PROCESSING. 

ENO 


Figure  6-26 


MODULE  NAME  * INTERRUPT  HANDLER 


OATA  REQUIRED 


TYPE  OF  EVENT  (EXTERNAL  OR  BUS  INPUT) 


DATA  PRODUCED 


NONE 

INTERRUPT  HANOLER 

this  function  saves  the  state  of  the  machine  and  transfers 
control  TO  HE  PROPER  INTERRUPT  RESPONSE  MOOULE 


LOCK  OUT  ALL  FURTHER  INTERRUPTS 
SAVE  PROGRAM  CTR 
SAVE  STACK  POINTERS 
SAVE  REGISTER  CONTENTS 

case  interrupt  tyre  (external  or  bus  inputi 
. "EXTERNAL  INTERRUPT" 

. "READ" 

ENOCASE 

RESTORE  MACHINE  STATE 
ENABLE  INTERRUPTS 
TRANSFER  TO  PROGRAM  CTR 

ENO 


Figure  6-27 
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MODULE  NAME  * DISPATCH 


DATA  REQUIRED 


INI T FLAG  I INITIALLY  PRESET  TO  0» 
NEW. MINOR. CYCLE. FLAG 
PERIODIC  PROGRAM  PARAMETERS 
-STACK.POINTER 
-DEPTH. OF. stack 


; 

! 

[ 


f 


DATA  PRODUCED 


NONE 


DISPATCH 

THIS  PROCESS  CALLS  ALL  THE  PERIODIC  PROCESSES 
EXECUTED  BY  THE  Z-Z . IT  IS  I HE  LOWEST  PRIORIIT 
PROCESS  AND  IS  PRE-EMPTED  BY  ALL  INTERRUPTS. 

IT  REPEATS  FOR  EACH  MINOR  CYCLE.  PERIODIC  PROCESS 
ARE  PRIORITIZED  BY  THEIR  POSITION  IN  THE  STACK. 


OOWHILE  POWER  IS  TM 

. IF  MEW. MINOR. CYCLE. FLAG  EQ  l AND  INIT.FLAG  EQ  l 
. . THEN 

. . SET  NEW. MINOR. CYCLE. FLAG  TO  0 

. . oowhile  stack  not  'inr 

. . . INITIALIZE  machine  S I A I e for  EACH  PERIODIC  PROCESS. 
. . . 'ACH  STACK  entry  POINTS  TO  A buffer  area  containing 
. . . INITIALIZATION  PARAMETERS. 

. . . CALL  PROCESS  REPRESENTED  3Y  STACK  ENTRY. 

. . ENODO 

. END  IF 

ENOOO 

END 


Figure  6-28 


MOOULE  NAME)  READ 


DATA  REQUIRED 


INPUT  MESSAGE  IASSUMEO  TO  BE  LOCATED  IN  I.M.  BUFFER! 
table  of  memory  buffer  locations  for  each  rcv  aoress. 
TABLE  OF  BUFFER  LENGTHS  FOR  EACH  RCV  ADORE  S S . 

Input  MESSAGE  RCV  AOORESS 


OATA  PROOUCEO 


Input  MESSAGE  IN  RCV  ADRESS  3UFFER 


Figure  6-29 


6-43 


NADC-79161-40 


READ 

THIS  MODULE  INPUTS  MESSAGES  FROM  THE  INTERFACE  MOOULE 

READ  RCV  ADDRESS 
IF  SOURCE  NODE  EQ  NODE  21 

. THEN 

. ACKNOWLEDGE  INPUT 
. ELSE 

. IF  RC V AOORESS  EO  30 

. . THEN  - 

. . INPUT  THREE  WOROS  TO  RCV  AOORESS  30  HESSAGE  BUFFER 

. . ACKNOWLEDGE  INPUT 

. . CALL  "COMMAND  PROCESSING"  MODULE 

. . ELSE 

. . TRANSFER  MESSAGE  TO  APPROPRIATE  INPUT  BUFFER 

. . ACKNOWLEDGE  INPUT 

. END  I F 

END  I F 

END 


Figure  6-30 


MODULE  NAME  I WRITE 


OATA  REQUIRED 


KMT  MESSAGE  AOORESS 

TABLE  OF  BUFFER  LOCATIONS  FOR  EACH  KMT  ADDRESS 
TABLE  OF  BUFFER  LCNGTHS  FOR  EACH  KMT  AOORESS 


OATA  PRODUCED 


OUTPUT  MESSAGE  TO  INTERFACE  MODULE 


WRITE 

THIS  FUNCTION  OUTPUTS  THE  SPECIFIEO  MESSAGE 
TJ  THE  INTERFACE  MOOJLE.  IT  WAITS  FOR  AN  ACKNOWLEDGE 
FOR  A SPECIFIED  PERIOD  OF  TIME.  NONE  OCCURING 
ERROR  CONDITION  IS  NOTED  IN  THE  STATUS  WORD. 

ENO 


Figure  6-31 
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TABLE  6-12.  NODE  32  DATA  FILES 


TRACK  FILE  (Contains  current  position  of  all  targets) 

— Track  ID 

— Fix  1 ID 

— Fix  2 ID 

— Fix  3 ID 

— Target  Latitude  (2  words) 

— Target  Longitude  (2  words) 

— Target  Grid  Coordinates  (U)  (2  words) 

— Target  Grid  Coordinates  (V)  (2  words) 

— Bearing 

— Target  Velocity 

— Target  Classification 

— Display  Cue 

FIX  FILE 

— Contact  ID 

— Fix  ID 

— Fix  Latitude  (2  words) 

— Fix  Longitude  (2  words) 

— Fix  Grid  Coordinates  )U)  )2  words) 

— Fix  Grid  Coordinates  (V)  (2  words) 

— Classification 

— Display  Cue 

— X Display  Coordinates 

— Y Display  Coordinates 

— Time  of  Fix  (2  words) 

SONOBl'OY  FILE 

— Sonobuoy  ID 

— Grid  Coordinates  (U)  (2  words) 

— Grid  Coordinates  (V)  (2  words) 

— Vector  Endpoint  (U)  (2  words) 

— Vector  Endpoint  (V)  (2  words) 

— Time  of  Update  (2  words) 

— Display  Cue 

— X Display  Coordinates 

— Y Display  Coordinates 

REFERENCE  MARK  FILE 

— Reference  Mark  ID 

— X Display  Coordinates 

— Y Display  Coordinates 

O 
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I 

Figures  6-32  through  6-60.  Node  SI  Operational  Functions 


n 

ZJ 
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NODULE  NAME  I DISPLAY  OUTPUT  PROCESSING 


DATA  REQUIRED 


T R AC'<  FILE 

FI*  FILE 

SONOBOUY  FILE 

OWN  A/C  PARAMETER  suffer 

TEXT  FILE 

PtRS.  INDICES#  FILE  PARAMETERS.  ETC 
REFERENCE  MARK  FILE 


DATA  PRODUCED 


UPDATES  OF  OUTPUT  SUFFERS 

BUE. 3  (TRACK  FILE-  30  WORDS ) 

BUF. R  (HOOK.  A / C , ANO  VECTOR  SYMBOLS  - 30  WOROS) 

SUE. 10  (FIXES.  SONOSaUYS,  ANO  REFERENCE  MARKS  - 30  WORDS) 
3UF.ll  (TEXT  FILE  - IS  WOROS) 


DISPLAY  OUTPUT  PROCESSING 

THIS  MODULE  UPDATES  TRANSMIT  SJB-AODRESSES  S,  0.  10.  AND  11 
IN  THE  FORMAT  DESCRIBED  IN  TABLE  6-.  _.  AND  TRANSMITS  THEM  EVERY 
MINOR  CYCLE 

SLOCK  1A-  HOdK  PUS  IT  ION 

insert  * and  r display  co-ordinates  of  hook  in  words  i and  2 of  suffer 

SLOCK  13-  A/C  POSITION 

READ  A/C  POSITION  CO-JRO  FROM  OWN  A/C  PARAMETER  SUFEER 
CONVERT  TO  X.Y  DISPLAY  CQ-ORO 
READ  HEAOlNl  FROM  OWN  A/C  PARAMETER  suffer 
CJNVEWT  TO  SIN.  CJS  DISPLAY  format 

insert  position  and  heading  data  in  words  3. 5. 6 of  buf.d 

SIOCK  1C  - VECTOR  INFORMATION  (BEARING  LINES  FROM  DIFAR  S0N0B0UYS) 

SET  I TO  1 

SET  WORDS  7 THRU  30  OF  3JF.9  TO  0 
SET  J TO  7 

DOWH I L £ I LE  NUM.S  ONOBOJ  YS  AND  J LE  10 

. IF  NE  W.SONO.FLAG ( I ) NE  0 

. . SET  NEW. SONO. FLAG!  I 1 TO  0 

. . IF  VECTOR  ENOPOINTS  FOR  ENTRYtll  NE  0,0 

. . . CONVERT  VECTOR  ENOPOINTS  IN  ENTRYtll  TO  X.Y  OISPIAY 

. . . CO-ORDINATES 

. . . insert  in  3uf_3  as  vector  enopoint  data  (words  j*2.  j ♦ i » 

. . . copy  sonobouy  position  co-ord  INTO  SUF.q  AS  VECTOR  start  POINT 

. . . DATA 

. . . (WORDS  J,  J «■  1 » 

. . . SET  VECTOR  ENOPOINTS  IN  SONOSQUY  FILE  YO  0,0 

. . . INCREMENT  j by  <. 

. . E NO  IF 

. END  I F 

. INCREMENT  I 
ENOOO 


Figure  6-32a 
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BLOCK  2-  UPOATE  BUF.8  (TRACK  INFO) 

SET  8UF.9  TO  0 
SET  I TO  I 
SET  J TO  1 

OOWH  II E I LE  NUN. TRACKS 

. IF  01  SR L AY  CUE  OF  TRACK  FILE  ENTRY ( I 1 NE  0 

. . CONVERT  POSITION  CQ-ORO  OF  TRACK(I)  TO  X.Y  DISPLAY  CO-ORO 

. . SET  OISPLAY  CUE  TO  0 

. . CONVERT  TINE-OF-UPDATE  TO  AL PHANUNER  IC S 

. . INSERT  CO-ORO  ANO  TINE  OF  UPDATE  IN  WORDS  J»  J*l,  ANO  J»2  OF 

. . 8UF.8 

. . INCRENENT  J 9Y  3 

. END  IF 

. INCRENENT  I 

ENOOO 

3L0CK  3-  UPDATE  BJF.IO  (FIX*  SONOBOUY.  AND  REFERENCE  NARKS) 

SET  J TO  l 

3L0CK  3A  (SONOBOUY  FILE) 

SET  I TO  1 
SET  3'JF.IO  TO  0 

OOWH IL E I LE  NUN  30N030JYS  AND  J LE  30 
. IF  NEW.SONO.FLAGI I 1 NE  0 
. . SET  NEW. SONO. FLAG! I ) TO  0 

. . CONVERT  SONOPOJY  [0  IN  CNTRY(I)  TO  NENQRY  AOORESS  (AO  THROUGH 

. . 127) 

. . INSERT  NENORY  ADDRESS  IN  WORO  J 

. . INSERT  X.Y  display  CO-OROINArES  IN  WORDS  J ANO  J*1 

. . CONVERT  OISPLAY  CUE  TO  3YNB0L  CODE 

. . INSERT  SYNBOL  C30F  IN  WORD  J»2 

• . IF  DISPLAY  CJE  INDICATES  SONOBOUY 

. . . THEN 

. . . IF  DIFAR  TY»E 

. . . . THEN 

. . . . SET  10  CHAR  I TO  "0" 

. . . . ELSE 

. . . . SET  ID  CHAR  1 TO  "L" 

. . . ENOIF 

. . . CONVERT  SONOBOJY  ID  TO  TWO  DIGIT  AL  ° H A NIJNE  R I C CDOE 

. . . INSERT  ALPHANUNERICS  IN  ID  CHAR  2*3 

. . . SET  TINE  ALPHANUNERICS  TO  BLANKS 

. . . ELSE 

. . . (CONTACT  OR  ACKNOWLEGED  CONTACT) 

. . . CONVERT  CONTACT  ID  TO  TWO  DIGIT  ALPHANUNERIC  CODE 

. . . SET  10  CHARACTERS  l ANO  2 IN  BUF.10  TO  ID 

. . . SET  10  CHAR  3 TO  BLANK 

. . . SET  TINE  ALPHANUNERICS  TO  T I NE -OF-UPO ATE 

. . ENOIF 

. . INCRENENT  J BY  6 

. ENOIF 

• INCRENENT  I 
ENOOO 

SET  I TO  1 

OOWHILE  I LE  NUN.FIXES  ANO  J LE  30 

• IF  NEW. FIX. FLAG! I I NE  0 

. . SET  NEW.FIX.FLAGII ) TO  0 

. . CONVERT  FIX  10  TO  NENORY  AOORESS 

. . INSERT  NENORY  AOORESS  IN  WORD  J 

. . INSERT  X.Y  DISPLAY  CO-ORO  IN  WORDS  J ANO  J»l 

. . CONVERT  OISPLAY  CUE  TO  SYNBOl  COOE 

. . INSERT  SYNBOL  COOE  IN  WORD  J*2 

. . CONVERT  FIX  10  TO  2 DIGIT  ALPHANUNERIC 

. . SET  10  CHARACTERS  I AND  2 TO  FIX  10  IN  WORDS  J*2.  J*3 

. . SET  10  CHAR  3 TO  BLANK 

. . SET  TINE  ALbHANUMERICS  TO  TINE  OF  FIX  (WOROS  J»A,  J*5I 

. . INCRENENT  J BY  B 


Figure  6-32b 
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I 


. ENOIF 

. I NC  RE  IE  NT  I 

ENOOO 

SET  I TO  1 

DOWHILE  I IE  NUM.REFERENCES  AND  J IT  30 
. IF  NE  W.REF  _FL  AG ( I I ME  0 
. . SET  NEW.REF.FLAGl l ) TO  D 

. . COPT  X.Y  DISPLAY  CO-ORO  INTO  WORDS  J ANO  J*l 

. . SET  10  CHAR  1 TO  "R" 

. . SET  10  CHARS  2 AMO  I TO  REPRESENT  "I" 

. . SET  TIME  ALPHANUMERICS  TO  BLANKS 

. . INCREMENT  J BY  t> 

. ENOIF 
. INCREMENT  I 
ENOOO 


3L0CK  A-  UPDATE  3JF.ll  (TEXT) 

IF  TAC.NA7  DISPLAY  FLAG  NE  0 
. THEN 

. SET  I TO  LAST  CHAR  OUT 

. set  j ro  last.x. position 
. SET  K TO  1 

. SET  3UF.11  TO  all  BLANKS 
. OOWHILE  I LE  IAST.CHAR.IN  ANO  J LE  23 
. . IF  TEXT  CHARI  II  EJ  CONTROL  CHAR 

. . . THEN 

. . . CASE  CONTROL  CHARACTER 

. . . . CARRIAGE  RETURN 

. . . . - SET  J TO  29 

. . . . BACKSPACE 

. . . . - SET  J TO  MAX ( J-l. 1 I 

. . . . -SET  < TO  MAX  ( K-l. 1 I 

. . . . -WRITE  BLANK  CHAR  IN  K TH  BUFFER  POSITION 

. . . . ERASE  LINE 

. . . . -ENTER  BLANKS  IN  3UF.ll 

. . . . -SET  J TO  29 

. . . . -DECREMENT  Y. POSITION  BY  DEL.Y 

. . . ENOCASE 

. . . ELSE 

. . . CJPY  CHAR  TO  BJFFER  POSITION  K 

. . . INCRENEMt  J 

. . . INCREMENT  LAST. X. POSITION 

. . . INCREMENT  K 

. . ENOIF 

. . INCREMENT  I 

. ENOOO 

. INSERT  L AST.X.POSI T ION,  Y. POSITION  IN  WORDS  1 AND  2 OF  3JF.ll 
. IF  J ED  29 
. . THEN 

. . SET  LAST. X. POSIT  ION  TO  MIN.X 

. . INCREMENT  Y. POSITION  3Y  OEL.Y 

. . IF  Y. POSITION  GT  MAX.Y 

. . . THEN 

. . . SET  Y. POSITION  TO  MIN.Y 

. . ENOIF 

. . ELSE 

. . SET  LAST.X  POSITION  TO  LAST.X  »OSITION»J  X OEL.X 

. ENOIF 

ENOIF 


ENO 


Figure  6-32c 
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MODULE  NANEi  CONMANO  PROCESSING  (DISPLAY) 


DATA  REQUIRED 


CONNANO  10 
FI*  FILE 
TRACK  FILE 
SONOBOUY  FILE 
REFERENCE  NARK  FILE 
TEXT  FILE 

POINTERS.  INDICES.  FILE  PARANETERS 

CENTER. OF. DISPLAY  VARIABLE 
TRACK. INTER RQGATE.NUKBER 


OATA  PRODUCED 


NONE 

COMNANO  PROCESSING  (DISPLAY) 

THIS  NODULE  IDENTIFIES  THE  INPUT  CONNAND  AND  CALLS  THE  PROPER 
SERVICE  ROUTINE.  IT  IS  ACTIVATED  0 Y THE  "READ"  CONNAND  UPON 
RECEPTION  OF  AN  ASYNCHRONOUS  NE35AGE. 

CASE  CONNAND  ID 
. !OIS»LAY  INtTt 
. (DISPLAY  CONFIGURE! 

. (ALPHAN'JNERIC! 

. (CLEAR  TACTICAL  PLOT! 

. (ACKNOWLEDGE  CONTACT! 

. IRC F E RF NCE  N AP < ! 

. iCLEAR  TE<U 
. (RECENIE3! 

. !H  A V I N I T ! 

. JNARK  TINE! 

. (READ  LAT/LONG! 

. (ENTER  FTP! 

. (TRACK  INTERROGATE! 

(ENTER  Ft*! 

. (OROP  SONOBOUY! 

. (OESTROY  F I * ( 

. (DESTROY  FTP! 

. ITERN INATE  NAVI 
. iNAO  RE-INIT! 

. iNAO  DISPLAY! 

. (ACTIVATE  FRP1 
. INAO  DISABLE! 

. !C  QMH  INITi 
. !C  JNN  TERN! 

. (NEW  NINOR  CYCLE! 

ENOCASE 

END 


Figure  6-33 
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SET  OISPLAY.INIT.FLAG  TO  1 

SEND  "NORTH  UP  NODE  INITIATE"  CND  TO  DISPLAY  NOOE  3? 

WRITE  "NAV  INIT"  CND  TO  NODE  70 

SET  CENTER.OF.OISPLAT  TO  PRESET  L AT 71  ON G 

INITIALIZE  FILE  STRUCTURES 

SET  TRACK.INTERROGATE.NUMOER  TO  l 

ENO 


OISPLAY  CONFIGURE 

SET  TAC/NAV. DISPLAY  FLAG  TO  1 
SET  SAO.l. RE. INIT. FLAG  TO  1 
SET  SAD. 3. TEXT. FLAG  TO  l 

ENO 


Figure  6-34 


ALPHANUNERIC 

THIS  NODULE  ACCEPTS  TEXT 
APPENOS  THEN  TO  THE  TEXT 

APPEND  CHARACTER  TO  TEXT 
INCRENENT  LAST.CHAR.IN 

END 


OR  CONTROL  CHARACTERS  ANO 
F ILE 

FILE 


Figure  6-35 


CLEAR  TACTICAL  PLOT 

THIS  NODULE  CLEARS  ALL  FIXES.  REFERENCE  NARKS.  VECTORS.  AND  TEXT 
FROH  THE  TAC/NAV  OISPLAT 

RE.INTIALIZE  FIX  FILE 

pre-initialize  text  file 
RE-INITIAL IZE  REFERENCE  NARK  FILE 
SET  NEW. FIX. FLAG  VECTOR  TO  0 LENGTH 
SET  NEw.REF.FLAG  VECTOR  TO  0 LENGTH 
SET  LAST.CHAR.IN  TO  1 

SET  ALL  COMPONENTS  OF  NE W. S ONO.F L AG  TO  1 
WRITE  OEDICATEO  NENORY  ERASE  COMMAND  TO  NODE  81 
WRITE  NON  DEDICATED  MEMORY  ERASE  COMMAND  TO  NOOE  8V 

ENO 


Figure  6-36 
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ACKNOWLEDGE  CONTACT 

WRITE  "ACKNOWLEDGE  CONTACT"  CONNANO  TO  NOOE  70 
DATA  WORDS  ARE  HOOK  X.T  POSITIONS 

END 


Figure  6-37 


REFERENCE  NARK 

ENTER  REFERENCE  NARK  10  IN  REFERENCE  NARK  FILE 

ENTER  X DISPLAY  CO-ORO 

ENTER  Y 01 SPL AY  CO-ORO 

APPENO  A "l"  TO  NEW. REF. flag  VECTOR 

END 


Figure  6-38 


RECENTER 

CALCULATE  NEW  CENT E » .OF . 0 1 S P L AY  t L AT /LONG ) FRON 
HOOK  POSITION  ANO  OLO  CE NT E R _0F_0 I SPL A Y 
SEND  "RECENTER  LAT"  CONNANO  TO  NODE  70 
(DATA  WORDS  ARE  LATITUDE ) 

SENT  "RECENTER  LONG"  CONNANO  TO  NOOE  70 
(DATA  WOROS  ARE  LONGITUDE  > 

SET  I TO  l 

OOWHILE  I LE  NUN.FIXES 

. UPDATE  X,Y  DISPLAY  CO-ORO  OF  ENTRY  I I ) 

. SET  NEW.FIX.FLAGIII  TO  1 

ENOOO 

SET  I TO  l 

OOWHILE  I LE  NUN.SONOBOJYS 
. UPOATE  X»Y  DISPLAY  CO-ORD  OF  ENTRY! I ) 

. SET  NEW.SONO.FLAGC I I TO  l 

ENOOO 

SET  I TO  1 

OOWHILE  I LE  NUH.REF ERENC E S 
. UPDATE  X # Y 0 I SPL  AY  CO-ORO  OF  ENTRY! I ) 

. SET  NEW. REF. FLAG! 1 1 TO  l 

ENOOO  - - - — 

WRITE  "OEOICATEO  NEN OR 7 ERASE"  CONNANO  TO  NODE  41 
WRITE  "NON— OE  0 IC  AT  E 0 NENORY  ERASE"  CONNANO  TO  NOOE  81 

ENO 


Figure  6-39 
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CLEAR  TEXT 

RE-INITIAL I?E  TEXT  FILE 
SET  LAST.CHAR.IN  TO  0 

WRITE  "NON-OEOICATEO  NENORY  ERASE"  CONNANO  TO  DISPLAY-NODE  81  '~ 


ENO 


Figure  6-40 

i 


NAV  IN  IT 

MR  I T E "NAV  INIT"  CONNANO  TO  NOOE  70 
ENO 

Figure  6-41 


CONN  INIT 

•RITE  "CONN  INIT"  CONNAND  TO  NODE  71 

LIST  PRESET  INITIALIZATION  OAT\  F OR  DATA  WORDS  1 AND  7 
ENO 

Figure  6-42 


CONN  TERN 

WRITE  "CONN  TERN"  CONNANO  TO  NODE  71 

ENO 

Figure  6-43 


i 


K 


I 
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NARK  TINE 

WRITE  "NARK  TINE"  CONNANO  TO  NODE  TO 
ENO 

Figure  6-44 


READ  IAT/LONS 

approximate  l at /long  from  hook  position  ano  center. of. display 

CONVERT  TO  ALPHANJNERICS 

APPEND  AlPHANUNERICS  TO  TEXT  FILE 

UPDATE  LAST.CHAR.IN 

ENO 


Figure  6-45 


ENTER  FTP 

WRITE  "ENTER  FTP"  CONNANO  TO  NODE  TO 
(HOOK  POSITIONS  ARF  DATA  WORDS) 

ENTER  FTP  ANO  HOOK  POSITIONS  IN  REFERENCE  MARK  FILE 
APPENO  A "1"  TO  NEW. REF. FLAG  VECTOR 

ENO 


Figure  6-46 
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" 


THIS  ROUTINE  BRINGS  THE  TRACK  SYMBOL  UP  ON  THE  TAC/NAV  DISPLAY 
ANO  PROVIDES  POSITION,  HEADING,  ANO  VELOCITY  I NFORNA  T I ON 
ON  THE  SA0.3  DISPLAY.  A SEOUENCE  OF  "TRACK  INTERROGATE"  CONNANOS 
WILL  GIVE  INFORMATION  ON  EACH  TARGET  IN  TURN.  AFTER  THE  LAST 
TARGET  IS  INTERROGATED,  THE  COMMAND  WILL  RETURN  OPERATION  TO  NORMAL 

IF  TRACK. INTERROGATE. NUMBER  E3  NUM.TRACKS 
. THEN 

. SET  TRACK. INTERROGATE. NUMBER  TO  0 _ ~ 

. ELSE 

. INCREMENT  TRACK. INTERROGATE. NUMBER  BY  I 

EMOIF  — 

IF  TRACK. INTERROGATE.NUMBER  NE  0 
. THEN 

. SET  DISPLAY  CUE  OF  TRACK  ENTRY  I TR  ACK.  I NTERROGATE.NUHBER ) TO  "TARGET""  

. SET  UP  TARGET  TABLEAU  IN  SAD. 3 OUTPUT  BUFFER 
. -TARGET  10  

. -LATITUOE 

. -LONGITUOE  

. -U  GRID  CO-ORO  

. -V  GRID  CO-ORD 

. -BEARING 

. -VELOCITY 

. -CLASSIFICATION " 

. CONVERT  TARGET  PARAMETERS  IN  TRACK  FILE 
. ENTRY! TRACK. INTERROGATE .NUMBER ) 

. TO  ALPHANUMERIC  AND  ENTER  IN  OUTPUT  BUFFER 
. ELSE 

. SET  SAO. 3. TEXT. FLAG  TO  l 

ENOIF 

ENO 


Figure  6-47 


ENTER  FIX 

SEND  "ENTER  FIX"  COMNANO  TO  NODE  70 
(DATA  WOROS  ARE  X.Y  HOOK  POSITIONS* 

END 


Figure  6-48 


OROP  SONOBOUY 

WRITE  "OROP  SONOBOUY"  COMMAND  TO  NOOE  70 
(NO  OATA  WORDSI 

ENO 

Figure  6-49 
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DESTROY  FIX 

SEND  "OESTROY  FIX*  COMMAND  TO  NOOE  70 
(OATA  WORDS  ARE  X.Y  NOOK  POSITIONS) 

SET  I TO  1 

SET  FINO.FLAG  TO  0 

OOWH1LE  I LE  NUM. FIXES  AND  FIND. FLAG  EQ  0 

IF  HOOK  POSITION  "CLOSE  ENOUGH"  TO  FIX  POSITION 
SET  FIND. FLAG  TO  l 
REMOVE  ENTRY  1 1 ) FROM  FILE 

REMOVE  COMPONENT ( I I FROM  NEW.FIX.FLAG  VECTOR 
SET  ALL  NEW.FIX.FLAG  COMPONENTS  TO  1 
SET  ALL  NEW.SONO.F LAG  COMPONENTS  TO  1 
SET  ALL  NEW.REF.FLAG  COMPONENTS  TO  1 
WRITE  "ERASE  DEDICATED  MEMORY"  COMMANO  TO  NODE  SI 
ENOIF 

INCREMENT  I ~ 

ENOOO 

END  

Figure  6-50 


DESTROY  FTP 

SENO  "OESTROY  FTP"  COMMAND  TO  NOOE  70 
(DATA  WOROS  ARE  X.Y  HOOK  POSITIONS) 

SET  I TO  1 

SET  FIND. FLAG  TO  0 

OOWH1LE  I LE  NUM. REFERENCE  S ANO  FIND  FLAG  EO  0 

IF  HOOK  POSITION  "CLOSE  ENOUGH"  TO  FTP  POSITION 
SET  FINO.FLAG  TO  1 
REMOVE  ENTRY! I)  FROM  FILE 

REMOVE  COMPONENT!!)  FROM  NEW.REF.FLAG  VECTOR 
SET  ALL  NEW.REF.FLAG  COMPONENTS  TO  1 
SET  ALL  NEW.SONO.FLAG  COMPONENTS  TO  1 
SET  ALL  NEW.FIX.FLAG  COMPONENTS  TO  1 
WRITE  "ERASE  OEOICATEO  MEMORY"  COMMAND  TO  NODE  81 
ENDIF 

INCREMENT  I 
ENODO 

ENO  ' ~ 


Figure  6-51 


terminate  nav 


SEND  "TERMINATE  NAV"  COMMAND  TO  NOOE  70 
NO  OATA  WOROS 

ENO 


Figure  6-52 
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NAO  RE .IN IT 

SENO  "NAO  RE.INIT"  CONNAND  TO  NOOE  TO 
(NO  OATA  WORDS  I 

END 

Figure  6-53 


NAD  01  SPLAY 

SEND  "NAO  OISPLAT"  CONNAND  TO  NOOE  70 
(NO  DATA  WORDS) 

ENO 

Figure  6-54 


ACTIVATE  FRR 

S F NO  "ACTIVATE  FRP"  CUNNANO  TO  NODE  70 
(NO  DATA  WORDS) 

ENO 

Figure  6-55 


NAO  DISABLE 

SENO  "NAO  DISABLE"  CONHANO  TO  NOOE  70 
(NO  DATA  WORDS) 

ENO 

STRUCTURE 

NEW  NINOR  CYCLE 

SET  NEW. NINOR. CTCLE.FLAG  TO  1 

ENO 

Figure  6-56 
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MODULE  NAME « SADI  UPOATE 


DATA  REQUIRED 


FTP.FLAG 

SAD_1.RE.INIT  FLAG 
OWN  A/C  PARAMETER  BUFFER 


DATA  PRODUCED 


SADI  OUTPUT  BUFFER 

-16  LINES  (66  ALPHANUMERIC  CHARACTERS  EACH) 

SADI  UPOATE 

THIS  MODULE  EXECUTES  APP ROX IMA TE L T EVERT  SECOND 

IF  FTP  FLAG  EO  1 
THEN 

IF  SA0_1.RE.INIT.FLAG  EO  1 

(INITIALIZE  SADI  BUFFER  FOR  STRAIGHT  LINE  FLIGHT  PATH) 
SET  LINE  1 TO  "NAVIGATION  INFORMATION" 

SET  LINE  Z TO  BLANKS 

SET  LINE  3 TO  "STRAIGHT  LINE  FLIGHT  PATH" 

SET  LINE  <•  TO  ALL  BLANKS 

SET  LINE  5 TO  "LATITUDE: OEGS MIN" 

SET  LINE  6 Tn  "L  ONG I T UOE  5 OEG! MIN" 

SET  LINE  7 TO  "HEAOING* OEG; MIN 

SET  LINE  8 TO  "AZIMUTH: OEG; MIN" 

SET  LINE  ? TO  "BEARING  TO  DESTINATION; OEG  ‘ 

SET  LINE  10  TO  "RANGE  TO  DESTINATION: NM" 

Sr.l  LINE  U TO  "TIME  TO  GO: MIN" 

StT  LINE  1Z  TO  BLANKS 

SET  LINE  13  TO  BLANKS 

SET  LINE  16  TO  BLANKS 

SET  LINE  15  TO 

SET  SA0.1_RE_INIT.FLAG  TO 
ENDIF 

READ  APPROPRIATE  INFORMATION  FROM  OWN  A/C  BUFFER 
CONVERT  TO  ALPHANUMER ICS 


"TIME  : HR  S ! min;. 

0 


.SEC" 


UPDATE  PROPER  LINES 

ELSE  

IF  SAO.l_RE.INI T.FLAG  EO  1 

(INITIALIZE  S AO  1 BUFFER  FOR  CIRCULAR  FLIGHT  PATH) 

SET  LINE  1 TO  "NAVIGATION  INFORMATION" 

TO  BLANKS 

TO  "CIRCULAR  FLIGHT  PATH" 

TO  BLANKS  

TO  "LATITUDE: OEG; MIN" 

TO  "LONGITUDE: OEG; MIN" 

TO  "U  POSITION: NM" 

"V  POSITION: NM" 

"BARO  ALT: FT" 

RADAR  ALT) FT" 

SET  LINE  ll  TO  "GROUNO  SPEED: KTS" 

SET  LINE  IZ  TO  "TRUE  AIR  SPEED: KTS" 

SET  LINE  13  TO  "MACH  NUMBER: " 

SET  LINE  16  TO  BLANKS 

SET  LINE  15  TO  "TIME: HRS; MIN) SEC" 

SET  SA0.1_RE.INIT.FLAG  TO  0 
ENOIF 

READ  APPROPRIATE  INFORMATION  FROM  OWN  A/C  BUFFER 
CONVERT  TO  ALPHANUMER IC S 
UPOATE  PROPER  LINES 
ENOIF 


SET  LINE 
SET  LINE 
SET  LINE 
SET  LINE 
SET  LINE 
SET  LINE 
SET  LINE 
SET  LINE 


TO 

TO 


SET  LINE  10  TO 


ENO 


Figure  6-57 
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NODULE  NAME!  SAD  2 UPDATE 


► 


OATA  REQUIRED 


CONFIGURATION  VEC  TOR(  FROM  NOOE  90) 

-BINARY  VECTOR  INDICATING  CONDITION  OF  ALL  NODES 
-"1"  IF  WORKING*  "0"  IF  FAILED 


OATA  PROOUCEDI 


SAD. 2 OUTPUT  DUFFER  JPOATE 
-16  LINES  OF  ALPHANUMERIC  DATA  FOR  SAO  2 
-ONE  LINE  IS  OUTPUT  EVERT  MINOR  CYCLE 
-EACH  LINE  IS  6A  CHARACTERS  LONG 


SAO  2 UPDATE 

THIS  NOOULE  EXECUTES  EVERT  MINOR  CYCLE 


THE  ALPHANUMER ICS  FOR  THIS  DUFFER  ARE  INITIALIZED  AS  FOLLOWS. 
AND  ARE  ONLY  UPDATED  WITH  THE  WORDS  "UP"  AND  "DOWN" 

LINE  U MAROWARE  STATUS 

LINE  21  BLANKS  ~ 

LINE  3:  COMM  (NODE  21) 

LINE  MAD  (NODE  30) 

LINE  5:  NAV  (NODE  73) 

LINE  6!  DISPLAY  (NODE  81) 

LINE  7:  KEYSET  (NODE  32) 

LINE  81  CONTROLLER  (NODE  90) 

LINE  91  DUS  I 
LINE  101  DUS  2 
LINES  11  -16  ( TOD) 


SET  I TO  l 
OOWHILE  I LE  8 

. IF  BIT(I)  OF  CONFIGURATION. VECTOR  EO  1 
. . THEN 

. . APPEND  "UP"  TO  LINE  1*2 

. . ELSE 

. . APPENO  "OOWN"  TO  LINE  1+2 

. END  IF 

ENDOO 

END 


Figure  6-58 
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OUTPUT  PROCESSING 


OATA  REQUIRED 


TEXT  FILE 
LAST.CHAR.IN 
-POINTER  TO  LAST 
LAST. CHAR. OUT 
-POINTER  TO  LAST 
LAST.CR 

- NUMBER  OF  CHAR 


CHARACTER  ENTEREO  IN  TEXT  FILE 
CHARACTER  OUTPUT  TO  BUFFER 

ENTEREO  IN  OUTPUT  BUFFER  SINCE  LAST  CARRIAGE  RETURN 


DATA  PROOUCEO 


UPOATES  OF  BUF./  (SAD 


OUTBUT  BUFFER  - XMT  SUB  AOORESS  Tl 


S AO  3 OUTPUT  PROCESSING 


THIS  MOOULE  EXECUTES  EVERY  MINOR  CYCLE 


IF 

S AO 

.3. 

T 

EXT. FLAG  EQ  1 

SET 

AL 

t 

WORDS  IN  BUF. 

7 

TO  0 

SET 

I 

T 

0 1 

SET 

J 

T 

0 LAST.CR 

OOWHILE 

LAST  CHAR. OUT 

l 

E LAST 

CHAR 

SET 

P TR  Tn  LAST.CH 
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TURN 

• 

• 

SET  LAST.CR 

TO 

0 
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• 

ENTER  CHAR  I 
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I 1 

. . . . INCREMENT  I 

. . . . -CASE  ?!  BACKSPACE 

• . . . IF  LAST.CR  ME  OTHEN  SET  LAST.CR  TO  LAST  CR 

. . . . ENOIF 

. . . . ENTER  CHAR  IN  8UF.7I I ) 

. . . . INCREMENT  I 

. . . . -CASE  3:  ERASE  LINE 

. . . . DOWHILE  LAST.CR  GT  0 

ENTER  BACKSPACE  IN  BUF. 7(1) 

INCREMENT  I 

DECREMENT  LAST.CR  " ~ ' 

. . . . ENDOO 

. . . ENOCASE 

. . . ELSE  

. . . IF  LAST.CR  LE  54 

. . . . THEN 

. . . . INCREMENT  LAST.CR 

. . . . ELSE 

. . . . SET  LAST.CR  TO  0 

. . . . ENTER  CARRIAGE  RETURN  IN  BUF_7(I)  

. . . . INCREMENT  I 

. . . END IF 

. . . ENTER  CHAR  IN  3UF.7I I ) 

. . . INCREMENT  I 

. . ENOIF 

. . SET  LAST .CHAR .OUT  TO  P TR 

. ENOOO 

. WRITE  BUF. 7 TO  INTERFACE  MODULE 
ENOIF 


ENO 


Figure  6-59 
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M00ULE  NAME  * DISPLAY  INPUT  PROCESSING 


DATA  REQUIRED 


INPUT  MESSAGE  BUFFERS 

-IN. 6 (RCV  SUB  ADORES  S 6 OF  TABLE  6-_.  - 20  WORDS  I 
-IN.7  ( 32  WDS ) 

-IN_9  (32  WOS) 

-IN.D  (32  WDS) 

-IN. 10  (32  WOSI 
-IM.ll  (32  WDS) 

-IN.12  (3  WDS) 

-IN.16  ( IQ  WDS) 

-IN.17  (21  WDS) 

-IN. 18  (22  WDS) 

-IN.IQ  ( 2 A WOSI 
-IN. 20  (2A  WDS) 

-IN. 21  (?A  WDS) 

- IN.22 ( 32  WOS) 

-IN.23  (2D  WOS) 


DATA  PRODUCED 


UPOATES  OF 
-FIX  FILE 
-TRACK  FILE 
-SONOBOUY  FILE 
-TEXT  F ILE 


DISPLAY  INPUT  PROCESSING 


BLOCK  1-  NAD  INPUT  (BUFFERS  6 THRU  12) 

THIS  3L0CK  WILL  AOD  NEW  TEXT  10  THE  SA0.3  IE»T  9UFFFER. 
IMPLEMENTATION  IS  DEPENDENT  ON  THE  MODIFICATION  OF  THE 
MAOTACS  PROGRAM. 


BLOCK  2-  NAY  INPUTS  (BUFFERS  16  - 23) 

BLOCK  2A  - PROCESS  IN. IS 

COPY  DYNAMIC  DATA  FROM  IN.16  INTO  OWN  A/C  PARAMETER  BUFFER 
3L0CK  29  - PROCESS  IN. 17 

CUPY  OYNAMIC  OATA  FROM  IN.17  TO  OWN  A/C  PARAMETER  SUFFER 
BLOCK  2C  - PROCESS  IN. 19 

COPY  DYNAMIC  DATA  FROM  IN. 19  INTO  OWN  A/C  PARAMETER  BUFFER 


BLOCK  20  - PROCESS  IN. IQ,  IN.20.  IN. 21  (FIX  FILE) 

(IT  IS  ASSUMED  THAT  THE  THREE  BUFFERS  ARE  CONSECUTIVE  IN  MEMORY) 
SET  I TO  l 

DOWHIIE  I LE  5 (6  FIX  ENTRIES  FILL  THREE  BUFFERS)  ~ 

. IF  01  SPLAY  CUE  OF  I"TH  FIX  NE  0 

. . CONVERT  U/V  CO-ORO IN  AT  ES  OF  FIX  TO  X,Y  OISPLAY  CO-ORD 

. . APPEND  X t Y DISPLAY  CO-ORO  TO  FIX  DATA 
. . APPENO  FIX  OATA  TO  FIX  FILE 
. . INCREMENT  NUM  FIXES 

. ENOIF  - - - 

. INCREMENT  I 
ENDOO 


Figure  6-60a 
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BLOCK  26  - PROCESS  IM_22  (TRACK  FILE! 

SET  I TO  1 
OOWHILE  I LE  ? 

. SET  J TO  l 

. OOWHILE  J LE  NJN.TRACKS 

. . IF  (TRACK  JO  OF  J"TH  ENTRY  IN  TRACK  FILE*  EO  (TRACK  10  OF  I"TH 

. . . ENTRY 

. . . IN  BUFFER  IN. 22) 

. . . THEN 

. . . CO»Y  I "T  H ENTRY  FROM  IN  22  INTO  J»TH  ENTRY  IN  TRACK  FILE 

. . ENOIF 

. • increnent  J 

. ENOOO 

. INCRENENT  I 

ENOOO 

BLOCK  2F  - R ROC  ESS  IN. 23  (S0N08OUY  FILE) 

IF  DISPLAY  CUE  OF  ENTRY  IN  BUFFER  IN. 23  NE  0 
. CONVERT  J/V  CO-ORDINATES  OF  ENTRY  TO  K,Y  DISPLAY  CO-ORD 
. SET  I TO  1 
. SET  FIND. FLAG  TO  0 

. OOWHILE  I LE  TJM. SUNOS  BUYS  ANO  FIND. FLAG  ED  0 

. . IF  ((ID  OF  ENTRY  I IN  SlNOUOUY  FILE)  ED  (ID  OF  ENTRY  IN  BUFFER 

. . . IN. 23) 

. . . SET  FIND. FLAG  TO  1 

. . . APPFNO  Y.Y  CO-ORDINATES  TO  SONOBOUY  DATA  FRQN  IN. 23 
. . . REPLACE  APPROPRIATE  ENTRY  IN  SONOBOUY  FILE  WITH  NEW  DATA 
. . . SET  NEW. SOSO. FLAG!  I)  TO  1 

. ENOIF 

. . INCRENENT  I 

. ENDOO 

. IF  FINO.FLAG  ED  0 

. . APPEND  J.Y  DISPLAY  CO-ORO  TO  DATA  FROM  IN.23 

. . APPEND  NEW  DATA  TO  SON0OOJY  FILE 

. . INCRENENT  NUN.SONOBOUYS 

. . APPEND  A "1"  TO  NEW.SONO  FLAG  VECTOR 

. ENOIF 

ENOIF 


BLOCK  3 - ENPTY  BUFFERS  FOR  NEW  DATA 

SET  ALL  BUFFER  WORDS.  IN  ALL  SUFFERS.  TO  0 

(3  IS  NOT  ALLOWED  AS  A TRACK  ID) 

END 


Figure  6-60b 


NADC-79161-40 


NOOULE  NAME « DISPLAT  SELF  TEST 


DATA  REQUIRED 


RESULTS  OF  SELF  TEST  PROGRAM 
2 STATUS  WORDS 

OLD  SEQUENCE  WORD  (SEQUENCE  WORO  LAST  TRANSMITTED) 
LAST  RETURN  WORD  INPUT  FROM  NODE  90 


DATA  PROOUCED 


9 WORD  SELF  TEST  MESSAGE  (9UF.J9) 

-NODE  ID,  MAJOR  CYCLE  NO,  MINOR  CYCLE  NO 

-STATUS  WORD  1 

-STATUS  WORD  2 

-CONFIGURATION  IDENT 

-RESULTS  OF  SELF  TEST  PROGRAM 

-OLD  SEQUENCE  WORO 

-RETURN  WORD 

-NEW  SEQUENCE  WORO 


01 

SPLAY  SELF  TEST 
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MINOR  CYCLE 
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T WORD  5 OF  9UF.29  TO 
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. THEN 

. CALL  APPROPRIATE  R 
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OVER 
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. SET  STATUS  WOROS  A 
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FIGURATION  I 
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TO  INDICATE 

. CONFIGURATION 

. ELSE 

. ATTEMPT  TO  ACTIVAI 
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Cl 
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OOWN  NECHANI 

SM 

NEW 


END  IF 

ELSE 

IF  NEW  MAJOR  CYCLE 
. INCREMENT  MAJOR  CYCLE  NO. 
. SET  MINOR  CYCLE  NO.  TO  D 
END  IF 


STATUS 

WORD  1 INTO 

stat 

JS 

WORO  l IN 

TO 

WORD 

t* 
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9UF.29 

TO 
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OF 

SUF.29 

TO 
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WORD 
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2 OF 
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ION  I 
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WORD 

8 TRA 

LAST 

WORD 

8 REC 

A NEW 

SEQUENCE 

MAJOR  CYCLE  NO,  MINOR  CYCLE  NO 


WRITE  9UF.29  TO  I.H. 
ENOIF 


END 


Figure  6-61. 
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6.6.3  Node  30 

6. 6. 3.1  General  Description 

Node  30  performs  two  major  functions.  It  performs  MAD  processing,  and 
it  acts  as  a monitor/backup  for  Node  90.  If  Node  90  (the  bus  controller)  fails. 
Node  30  will  initiate  control  of  the  bus. 

6.6. 3.  2 I/O  Description 

Node  30  is  relatively  self-contained.  It  receives  MAD  sensor  data  from 
Node  115  and  navigation  and  contact  information  from  Node  70,  processes  the 
data,  and  alerts  Node  70  (the  navigation  subsystem)  if  a detection  is  made.  This 
node  accepts  control  commands  from  Node  82  and  sends  display  data  to  Node  82, 
if  required.  Node  30  input  and  output  messages  for  the  implementation  subset 
are  shown  in  Tables  6-13  and  6-14,  respectively. 

For  the  purpose  of  this  implementation  subset,  the  use  of  Node  30  synchronous 
output  messages  to  Node  82  was  considered  sufficient  to  transmit  to  the  display 
those  statistical  data  that  are  produced  as  output  by  the  existing  MAD  program 
described  in  the  previous  paragraph.  Data  rates  and  bus  loading  will  therefore 
be  maintained,  but  meaningful  data  will  still  be  passed  to  the  display. 

Node  30  also  sends  a self-test  message  to  the  bus  controller  every  minor 
cycle  and  likewise  receives  a self-test  message  from  the  controller. 

6. 6. 3.  3 Software  Modules  Descriptions 

6. 6. 3. 3. 1 Executive  Control  Processing.  Assume  that  the  SDEX-M  (Reference 
22)  executive  will  be  implemented  in  Node  30,  since  the  node  is  an  AN/AYK-14 
computer.  This  executive  functions  when  an  application  process  makes  an  exec- 
utive service  request  (ESR). 

It  will  also  be  necessary  to  have  the  bus  controller  program  resident  in 
Node  30  in  case  Node  90  fails. 
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6.6.3. 3. 2 Operational  Modules.  These  modules  perform  MAD  processing,  as 
a result  of  receiving  input  command  from  Node  82. 

a*  Input  Command  Processing  — Input  Command  Processing  is  a module 
invoked  when  an  asynchronous  bus  message  is  received  by  Node  30. 

This  module  interprets  the  first  message  word  as  a command  word. 

The  remaining  message  words  contain  any  necessary  data  for  the  ex- 
ecution of  the  command.  Figures  6-62  through  6-67  present  functional 
descriptions  of  the  Input  Command  Processing  module  and  its  associ- 
ated subroutines. 

b.  MAD  Processing  — The  MAD  Processing  module  detects  and  localizes 
a target  based  on  the  outputs  of  simulated  magnetometer  signals  (one 
frequency  value  every  50  milliseconds).  This  program  was  originally 
written  for  the  CP-IO  machine  in  the  SPL/I  language  by  Code  503  per- 
sonnel. The  SPL/I  compiler  for  the  AN/ AYK-14  is  now  available  and 
allows  this  program  to  be  used  to  exercise  the  AN/ AYK-14  in  this 
simulation  problem.  Minor  modifications  will  have  to  be  made  in  the 
I/O  routines,  but  these  should  have  minimum  cost  impact.  Figures 
6-68  through  6-72  present  a structured  description  of  the  program, 
while  Appendix  A1  is  a listing  of  the  compilation  of  the  program. 

6. 6. 3. 3.  3 Test  and  Reconfiguration  IV.  Node  30  monitors  Node  90  (Bus  Con- 
trol) and  acts  as  backup  for  it  in  case  of  failure.  This  node,  like  every  node, 
performs  self-test  program  every  minor  cycle. 

a*  Controller  Monitor  (see  Figure  6-73)  — Node  30  is  designated  as  the 
backup  controller  for  Node  90.  As  such,  it  receives  and  verifies  the 
Node  90  self-test  messages  produced  by  the  periodic  execution  of  the 
Node  90  self-test  program.  If  the  Node  90  self-test  message  indicates 
a failure,  Node  30  will  verify  the  self-test  message  by  checking  the 
message  Node  30  received  with  the  same  message  as  received  by  Node 
70.  If  the  Node  70  message  also  indicates  a failure,  a discrete  inter- 
rupt line  is  activated  which  will  remove  power  from  Node  90,  thus 
isolating  it  from  the  bus.  Node  30  will  then  take  over  test  and  monitor 
functions  for  the  system  through  execution  of  the  reconfiguration  program. 

b.  Reconfiguration  (see  Figure  6-74)  — This  program  loads  in  the  programs 
normally  executed  by  Node  70  and  schedules  them  as  Node  30  tasks;  this 
procedure  allows  recovery  from  a Node  90  failure. 

c.  Self-Test  (Figure  6-75)  — During  every  minor  cycle,  Node  30  will  ex- 
exute  a self-test  program  and  format  an  appropriate  message  to  the  bus 
controller  indicating  its  status.  The  self-test  program  is  the  IFPM 
program  developed  for  the  AN/AYK-14,  and  the  message  format  is 
shown  in  Table  6-7. 


Appendix  A is  a separate  volume  available  from  NAVAIRDEVCEN  Code  502. 
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H00M.E  NANEI  INPUT  COHHANO  PROCESSING 


OAT  A REQUIREO 


MOOT  A2  ASYNCHRONOUS  HSG 
.COHHANO  WORO 
.DATA  MORO  1 
.DATA  MORO  2 


DATA  PROOUCED 


NONE 


input  connano  processing 

This  NOOULE  INTERPRETS  the  COHHANO  A N 0 CALLS  T-  F APPROPRIATE 

LOCAL  SUBROUTINE 

CASE  COHHANO  WORD 

. SHAO  RE-INITI 

. iHAJ  DISPLAYS 

. {ACTIVATE  FRPS 

. SHAO  HARKS 

. SHAO  DISABLES 

ENOCASE 

ENO 


Figure  »j— «32 


NAO  RE-IHIT 

This  SUJROUTINE  RESE'S  The  INITIAL  VAL'JFj  Of  TMF  HAD  SU8PP0C.OAH 
TO  PRESET  VALUES 

ENO 


Figure  6-63 
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this  subroutine  sets  the  format  options  for  thc 

•MAO  PROCESSING*  MOCULE  ACCORDING  to  ThE  VA1.UE  OF  DATA  WORD  1. 
ANO  ACTIVATES  THE  *NAO  PROCESSING*  TASK 


ENO 


Figure  6-64 


ACTIVATE  FRP 

this  subroutine  set;  the  flag  injicating  that  feature  recognition 

PROCESSING  IS  TO  BE  PERFORMED  BY  'Mf  • M A n PROCESSING*  NOCULt 
SET  FRP. OUTPUT. FLAG  TO  1 

ENO 


Figure  6-65 


I 


NAO  MARK 

THIS  MOOULE  SENOS  AN  -ENTER  FJ*-  COMMAND  TO 

NODE  TO  (NAV),  MITM  tM£  Fix  10  INOICATEO  IN  OATA  *0*0  t 

ENO 


Figure  6-66 


MAO  OISABLE 

TMIS  SUBROUTINE  TERMINATES  TMg  »MAO  PROCFSSIMP,*  MOOULE 

ENO 

Figure  6-67 
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MODULE  NAME:  (MAO)  MAGNETIC  ANOMALY  DETECTION 


DATA  REQUIRED 


INPUT  SIGNAL  DATA 

sample  window  fop  each  channel 

PREPARE  DETECT  FLAG 

LOCALIZATION  flag 

SEQUENCE 

TAHLE  FOR  EaCm  SEQUENCE 

NUMhER  OF  SEGuENCES 

EaPECTED  CMANNtL  OF  EACH  SEQUENCE 

CHANNEL  PROCESSOR  FLAGS 

time  limit  clock  for  each  channel 

LOCK  OUT  TIMER  FOR  EACH  CHANNEL 


DATA  PRODUCED 


Sample  window  for  Each  Channel 
Channel  processor  flags 
prepare  detect  flag 
slant  range 
confidence  level 

RETROMARK  time 
LOCALIZATION  STAT  flag 
NUMBER  OF  SEQUENCES 

localization  flag 

E XPECTFO  CHANNEL  OF  EACH  SEQUENCE 
SEOUF NCE 

Channel 

TIME  LIMIT  CLOCK  FOR  EACH  CHANNEL 
LOCK  OUT  TIMER  FOR  EACH  CHANNEL 


Figure  6-68a 
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• PREPROCESSING  CYCLE 

• 

lOWPASS  FILTER  INPUT  SIGNAL  O A T A 

PUT  DATA  IN  SAMPLE  WlNUOw$  OF  APPROPRIATE  CHANNELS  ANO  SET  THE 
COPPE'SPONOlNG  Channel  PROCESSOR  flags  (SAMPLE  VECTOR  GENERATION) 

• 

•END  OF  PREPROCESSING  CYCLE 


(EXECUTION  CYCLE:  DETERMINE  ANO  PROCESS  THE  HIGHEST  PRIORITY  TASK) 
IF  PREPARE  DETECT  IS  AWAITING  EXECUTION 
. THEN 

. ^DETECTIONS 

. • LIKELIHOOO  .COMPUTATIONS 

. * SEQUENCE  PROCESSING 

, *•••« 

. RESET  PREPARE  DETECT  FLAG 
. ELSE 

. IF  LOCALIZATION  IS  AWAITING  EXECUTION 

. . THEN 


* localization  CYCLE 

* LOCALIZE  USING  the  INFORMATION  from  the  SEQUENCE’S  TABLE 

* 

COMPuTt  - slant  range. CONF IDtNCE  LEVEL,  AND  RETROMARK  TIME 
DISPLAY  STATISTICS  (SET  LOCALIZATION  STAT  FLAG) 

HAVING  CONCLUDED  SEUUENCE  PROCESSING  DECREMENT  NUMBER  OF 
SEQUENCES 

IF  THE  OTHER  SEQUENCE  DOES  NOT  REQUIRE  PROCESSING 
. (ThE  EXPECTED  CHANNEL  OF  THE  SEQUENCES  DIFFER) 

. THEN 

. RESET  LOCALIZATION  FLAG 
ENDIF 

SET  EXPECTED  CHANNEL  OF  SEQUENCE  TO  NONt  (7) 

SET  SEQUENCE  (TABLE  POINTER)  TO  THE  OTHER  SEQUENCE 
« 

•END  OF  LOCALIZATION  CYCLE 


. . ELSE 

. . IF  A CHANNEL  PROCESSOR  IS  AWAITING  EXECUTION 

. . . THEN 

. . . ^PROCESS  Channels  for  the  lowest  channel  processor  waiting 

• • • ***** 

. . . • SIGNAL  description 

. . . • PRELIMINARY  detection  testing  / epoch  tracking 

• • • ••••• 

. . . ' UPDATE  CHANNEL’S  TI*E  LIMIT  CLOCK 

. . . UPOATE  CHANNEL’S  LOCK  OUT  TIMER 

. . . RESET  CHANNEL  PROCESSOR  FLAG 

. . ENOIF 

. ENOIF 
ENOIF 

(WAIT  FOR  NEXT  INPUT  SIGNAL  DATA) 

EN0  Figure  6-68b 
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module  name:  detection 


DATA  REQUIRED 


CHANNEL 

LIKELIHOOD  PRODUCT  THRESHOLD  FOR  EACH  CHANNEL 

EXPECTED  CHANNEL  OP  EACH  SEQUENCE 

LOCK  OUT  TIMER  FOR  EACH  CHANNEL 

NUMBER  OF  SEQUENCES 

SEQUENCE 

LENGTH  OF  tACH  SEQUENCE 
SAVED  COPY  OF  SIGNAL  METRICS 
time  limit  CLOCK 


DATA  PRODUCED 


TIMESLICE  STATISTICS 
LIKELIHOOD  product 
DETECTION  FLAG  FOR  CHANNEL 
SEQUENCE 

SEQUENCE  TABLE  POINTER 

LENGTH  OF  EACH  SEQUENCE 

NtjMRFH  OF  SEQUENCES 

LOCK  OUT  TIMEP  F OH  EACH  CHANNEL 

TIME  LIMIT  CLOCK  FOR  EACH  CHANNEL 

alert  flag 

EPOCH  flag  OF  CHANNEL 

EXPECTED  Channel  OF  EACH  SEQUENCE 

SEQUENCE  TABLE  STATISTICS 

localization  flag 

SAVED  COPY  OF  SIGNAL  METRICS 
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DETECTION 

COMPUTE  TImESLICl  STATISTICS  AND  Th£  LIKELIHOOD  PRODUCT 
IF  LIKELIHOOD  PRODUCT  EXCEEDS  This  CHANNEL’S  LIKELIHOOD  PRODUCT 
. THRESHOLD 

. THEN 

. < PROCESS  SEQUENCE) 

. SET  DETECTION  FLAG  OF  CHANNEL 

. IF  CHANNEL  WAS  NOT  EXPECTED  BY  EITHER  SEQUENCE 

. . THEN 

. . (TRY  TO  INITIATE  A nEw  SEQUENCE) 

. . IF  LOCKOUT  TIMER  OF  THIS  CHANNEL  HAS  NOT  EXPIRED  OR  THE  NUMBER  OF 

. . . SEQUENCES  EXCEEDS  1 

. . . THEN 

. . . EXIT  FROM  PREPARE  FOR  DETECTION 

. . . ELSE  1 

. . . (INITIATE  NEW  SEQUENCE) 

. . . INCREMENT  numhER  OF  SEQUENCES  . 

. . . SET  SEQUENCE  TO  THE  FIRST  AVAILABLE  TABLE 

„ . . SET  LtNGTH  OF  THIS  SEQUENCE  TO  0 

. . . SAVE  Channel  INITIATING  SEQUENCE 

. . . SET  The  LOCK  OUT  TIMERS  FOR  THIS  AND  HIGHER  CHANNELS 

. . . SET  THE  TIME  LIMIT  CLOCKS  FOR  THE  NEXT  2 CHANNELS 

. . . SAVt  AIwCRAFT  VELOCITY 

. . . ACTIVATE  CONFIRMING  ALE"T  (SET  AlERT  FLAG) 

. . ENOIF 

. END  IF 

. DOWHILE  CHANNEL  is  expected  by  sequence 
. . INCREMENT  length  of  SEQUENCE 

. . SET  EPOCH  FLAG  OF  CHANNEL  TO  SEQUENCE 

. . SET  EXPECTED  CHANNEL  OF  SEQUENCE  TO  THE  NEXT  CHANNEL 

. . TPANSFER  SAVED  SIGNAL  METRICS  TO  SEQUENCE  TAbLt 

. . SAVE  TIME  OF  CONFIRMATION  AND  LIKELIHOOD  PRODUCT 

. . SET  SEQUENCE  TO  ? 

. ENDDO 
. ELSE 

. SAVE-  CURRENT  SIGNAL  METRICS 

. IF  TIME  LIMIT  CLOCK  OF  TrilS  CHANNEL  HAS  EXPIRED  WHILE  THE  CHANNEl. 

. , WAS  EXPECTED  BY  ONE  OF  THE  SEQUENCES 

. . THEN 

. . SET  LOCALIZATION  FLAG  FOR  PROCESSING  OF  TARGET  INFORMATION  ON  ThE 

. , NEXT  CYCLE  AS  NO  MORE  CHANNEL  INFORMATION  IS  ADMISSIBLE 

. END  I F 
ENDIF 

END 


Figure  6-69b 
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MODULE  name:  PROCESS  CHANNEL 


DATA  REQUIRED 


CHANNEL 
sample  WINDOW 
AVERAGE  POWER 
SIGNAL  POWER  HISTORY 
GAMMA  HISTORY 

epoch  flag  for  channel 

EPOCH  HISTORY 

time  LIMIT  clock  for  This  and  next  channel 
EXPECTED  CHANNEL  0E  EACH  SEQUENCE 
DETECTION  Flag  eor  channel 
SAVED  AVERAGE  POWER  level 


DATA  PROOUCED 


SAMPLE  vector 
SIGNAL  METRICS 
-INPUT  SIGNAL  POwER 
-4NDERSON  COEFFICIENTS 
-SIGNAL  POWER  ESTIMATE 
-gamma 

-NOISE  POwER 
AVERAGE  POwER 
SIGNAL  EVENT  THRESHOLD 
SIGNAL  POWER  history 

GAMMA  HISTORY 
EPOCh 

EPOCH  HISTORY 

LOCALIZAT ION  FLAG 

EPOCH  FLAG  FOR  CHANNEL 

SAVED  AVERAGE  POWER  LEVEL 

PREPARE  DETECT  FLAG 

SAVED  COPY  OF  SIGNAL  METRICS 

DETECTION  FLAG  FOR  CHANNEL 


Figure  6-70a 
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1 

GENERATE  CHANNEL'S  NORMALIZED  SAMPLE  VECTOR  FROM  SAMPLE  WINDOW  aY 
REMOVING  RAMP  ANO  OC  BIAS 

CHARACTERIZE  SIGNAL  BY  CALCULATING:  INPUT  SIGNAL  POWER#  ANDERSON 
COEFFICIENTS.  SIGNAL  POWER  ESTIMATE#  GAMMA,  NOISE  POWER#  AVERAGE 
POWER#  SIGNAL  EVENT  THRESHOLD 
UPDATE  SIGNAL  POWER  ANO  GAMMA  HISTORIES 
COMPUTE  FPOCH  (OE TERMINATOR)  AND  UPDATE  ITS  HISTORY 

IF  AN  EVENT  HAS  bEEN  CONFIRMED  ON  THIS  CHANNtL  (EPOCH  FLAG  OF  THIS 

. channel  is  not  o> 

. THEN 

. IF  A minimum  in  EPOCH  has  OCCURRED 

. . THEN 

. . SET  SEQUENCE  TO  EPOCH  FLAG  OF  CHANNEL 

. . SAVE  DATA  FOR  epoch  detewminator  • 

. . IF  This  is  CHANNEL  6 OR  SEQUENCE  LENGTH  IS  3 OR  CHANNELS  IS 
. . . EXPECTED  AND  ITS  TIME  LIMIT  CLOCK  HAS  EXPIRED 

. . . THEN 

. . . SET  LOCALIZATION  FLAG 

. . END  I F 

. . RESET  EPOCH  Flag  OF  CHANNEL  TO  0 

. END  IF 
. ELSE 

. SET  SEQUENCE  TO  FIRST  TAbLE  EXPECTING  THIS  CHANNEL  (OR  0) 

. IF  an  EVENT  OCCURRED  (SIGNAL  POWER  EXCEEDS  EVENTTHREShOLD) 

. . THEN 

. . SAVE  CURRENT  AVERAGE  POwER  LEVEL  AS  BASIS  FOR  NEXT  EVENT  AS 

. . REQUIRED 

. . 1^  A mAaIMum  in  gamma  has  OCCURRED 

. . . THEN 

. . . SET  PRtPARE  DETECT  FLAG 

. . . ELSE 

. . . SAVE  CURRENT  SIGNAL  METRICS 

. . . IF  TIME  LIMIT  CLOCK  OF  THIS  CHANNEL  HAS  EXPIRED  WHILE  ThE 

. . . . CHANNEL  WAS  ExPtCTEu  BY  ONE  OF  THE  SEQUENCES 

. . . . THEN 

. . . . set  localization  flag  for  processing  of  target  information 

. . . . ON  The  next  CYCLE  AS  NO  MORE  CHANNEL  INFORMATION  IS 

. . . . ADMISSIBLE 

# . . ENDIF 

. . ENDIF 

. . ELSE 

. . IF  The  DETECTION  Flag  of  Channel  IS  SET 

. . . THEN 

. . . RESTORE  AVERAGE  POWER  LEVEL  TO  THE  VALUE  SAVED  WHEN  ThE  EVENT 

. . . * OCCURRED 

. . . RESET  DETECTION  FLAG  OF  CHANNEL 

. . ENDIF 

. . IF  TIME  LIMIT  CLOCK  OF  THIS  CHANNEL  HAS  EXPIRED  WHILE  THE  CHANNEL 
. . . WAS  EXPECTED  hy  ONE  OF  THE  SEQUENCES 

. . . THEN 

. . . SET  LOCALIZATION  FLAG  FOR  PROCESSING  OF  TARGET  INFORMATION  On 

. . . THE  NEXT  CYCLE  AS  NO  MORE  CHANNEL  INFORMATION  IS  ADMISSIBLE. 

. . ENDIF 

. ENDIF 
ENDIF 

END  Figure  6-70b 
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MODULE  NAME:  CONTROL  PROGRAM  FOR  MAD 
DATA  REQUIRED 


ALERT  Flag 

localization  STat  Flag 
machox  operation  flag 
MISC.  run  TIME  OPTIONS 


OATA  PRODUCED 


alert  flag 

localization  stat  flag 

CONTROL  PROGRAM  FOR  MAO 

SET  INITIAL  CONDITIONS  FOR  PROGRAM  ACCORDING  TO  RUN  TIME  SETTINGS 
IF  “ADROX  OPERATION  IS  REQUESTED 

. THEN 

. REGISTER  iMAULOOPING  PROGRAM*  5^'^b 

. Turn  on  MALI  ISC  nUX  (WHICH  WILL  INVOKE  MAULOOPING  PROGRAM  AT  1/20TW 
. SECOND  INTERVALS) 

. ELSE 

. (OPERATE  OEE  OE  maG-TAPE  DATA) 

. DISCARD  FIRST  RECORD  OE  OATA  (OPTIONAL) 

. DOWHILE  (TRUE) 

. . READ  a RECORD  OF  DATA  - l SAMPLES  (OPTIONAL  ThE  FIRST  TIME) 

. . OPTIONALLY  Dump  DATA  TO  Pr I NTtP 

. . SET  COUNTER  To  1 

. . DOWHILE  COUNTER  IS  LESS  THAN  1?6 

. . . EXECUTE  mao  WITH  SCALED  SAMPLE  (COUNTER) 

. . . OPTIONALLY  DUMP  intermediate  results 

. . . IF  alert  Flag  is  set 

. . . . THEN 

. . . . RESET  ALERT  FLAG 

. . . . SIGNAL  The  AlERT  ON  The  LINE  PRINTER 

. . . ENDIF 

. . . IF  LOCALIZATION  STAT  FLAG  IS  SET 

. . . . THEN 

. . . . RESET  LOCALIZATION  STAT  FLAG 

. OUTPUT  STATISTICS  ON  Th£  HAZELTINE  OR  THE  LINE  PRINTER 
. . . . PRINT  STATISTICS 

. . . ENDIF 

. . . INCREMENT  COUNTER 

. . ENDDO 

. . OPTIONALLY  OUMP  Channel  HISTORY  STATISTICS 

. . OPTIONALLY  STOP  EXECUTION  FOR  OPERATOH  INTERVENTION 

. ENDDO 
ENDIF 

END  Figure  6-71 
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HADL00PIN6  PROGRAM  FOR  REAL-TIME  OPERATION  WITH  SUB-SIMULATOR 

(INVOKED  AS  A SELECTED  EVENT  T ASA  ON  RECEIVING  AN  INTERRUPT  AND  INPUT 
SIGNAL  FROM  Th£  ISC) 

MASK  AND  SCALE  INPUT  b I ijN  A|_ 

IF  mag  dump  Flag  IS  SET 

. THEN 

. DUMP  SCALc.0  SIGNALS  ONTO  TARE  (SAm£  FORMAT  AS  USED  FOP  TAPE 
. OPERATION) 

. ELSE 

. EXECUTE  MAO  «ITh  SCALED  SIGNAL 
. if  alert  flag  is  set 

. . THEN 

. . PESET  « L t P T FLAG 

. . SIGNAL  ThE  alERT  ON  ThE  LINE  PRINTER 

. ENDIF 

. IF  LOCALIZATION  STAT  FLAG  IS  SET 

. . then 

. . RESET  LOCALIZATION  STAT  FLAG 

. . OUTPUT  STATISTICS  ON  ThE  hAZELTINE  OR  Th£  LINE  PRINTER 

. . PRINT  STATISTICS 

. ENDIF 
ENOIF 

END 


Figure  6-72 
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NODULE  NAME!  CONTROLLER  MONITOR 


OATA  REQUIREO 

NODE  *0  OUTPUT  SELE  TEST  MFSSAGt 

NODE  ED  REPEAT  OF  NO CE  90  OUTPUT  MESSAGE 

OATA  PROOUCEO 


NONE 


CONTROLLER  MONITOR 

this  module  is  activated  at  a 

CTCLE  OR  BY  AN  INTERRUPT  WHICH  OCCURS  whFN  A CERTAIN  PRESET  AMOUNT 

OF  TIME  OCCURS  WITHOUT  A NEW  MINOR  CYCLE  COMMA"!1  BEING 

RECEIVES 

VERIFY  NOOE  13,  MAJOR  CYCLE  NO,  MINOR  CYCLE  NO.  FROM  WORE  1 
OF  RECcIVED  MESSAGE 

VE’iFY  STATUS  WORDS  OK  (WO=OS  Z AND  1 OR  MESSAGE) 

SA /E  CONF IGURAT ION  It 
VERIFY  IFPM  RESULTS  OK 

VERIFY  that  last  WO=r  • of  nod  30  SEE F T^ST  “ESSAGF  SENT 
EOUALS  WQRO  T OF  THIS  MESSAGt 

VERIFY  THAT  LAST  WOP"'  A OF  NOOE  SO  3EEF  ? F$  T MFSSAG  E 
EOUALS  WORO  6 OF  THIS  mcs$«qf 
SAVc.  HORC  3 OF  THTS  MESSAGE 
IF  ANY  VERIFY  FAILS 

. THEN 

. ACTTVaTE  9US  GONYRCE  FOR  DUS  ? 

. REA  J LAST  NOOE  TO  SELF  TEST  MESSAGE  FROM  NO  E 70 
. IF  MESSAGES  CO  NCT  AGREE 

. . THEN 

. . SIGNAL  OPERATOR  'SYSTEM  FAILURE  NOT  ISOLATES' 

. . ELSE 

. . SIGNAL  OPERATOR  ’ NC3E  90  FAILURE?  <=  FO  ONF  ! GURA  T ION  ATT  EHPTE  C ' 

. . ACTIVATE  DISCRETE  NOCE  90  SHUTOOUN  INTERPUPT  TPRlFERRASLY  A POWER 

. . SHUTDOWN  ' 

. . CALL  'RECONFIGURATION* 

. ENDIF 
ENOIF 

END 


Figure  6-73 


Node  30  Controller  Monitor  Function 
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MODULE  NAME  I RECONFIGURATION 


OAT  A REQUIRED 


RECONFIGURATION  PROGRAMS  FROM  OISK  THROUGH  NOPE  21 


DATA  PROOUCEO 


SIGNAL  TO  OPERATOR  'RECONFIGURATION  COMPLETE' 


RECONFIGURATION 

SUSPEND  NEW  MINOR  C yCLE  MESSAGES 
SET  LAST  TO  0 

OOHHILE  LAST  EO 

. WRITE  ' RFAO  Block'  COMMAND  TO  mass  MEMORT  ( "OOE  211 
. LOOP  UNTIL  BLOCK  IS  RECEIVEO 
. TRANSFER  oLOCK  TO  PROPER  MEMORT  location 
. IF  ALL  PROGRAMS  TwANSFFRRt.0 
. . THEN 

. . aE  T LAST  TO  1 

. E NO  IF 

ENOOO 

»E  >ET  MINOR  CYCLE  T IME 
ACTIVATE  »OOMMANO  PROCESSING*  module 
ACTIVATE  'CONFIGURATION  MONITOR*  MODULE 
ACTIVATE  'STATISTICS*  MOOULE 
ACTIVATE  'SELF  TEST*  MOOULE 
ACTIVATE  *MAO  PROCESSING*  module 

SIGNAL  OPERATOR  THAT  RECONFIGURATION  IS  COMPLETE 

ENO 


Figure  6-74 


Node  30  Reconfiguration  Function 
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MODULE  NAME < MAO  SELF  TEST 


OATA  REQUIRED 


RESULTS  CF  SELF  TEST  PROGPAH 
2 STATUS  WORDS 

OLD  SEQUENCE  word  I SF  CUENCE  WORO  LAST  TRANSMITTED* 
LAST  SETURM  WORO  INPUT  FROM  NOOl  “I 


OATA  PRODUCED 


8 WORO  SELF  TEST  MESSAGE  (8UF.29* 

-NODE  IJ,  MAJOR  CYCLE  NO,  MINOR  CYCLF  NO 

-STATUS  WORO  1 

-STATUS  WORO  Z 

-CONFIGURATION  ICENT 

-RESULTS  OF  SELF  TEST  PROGRAM 

-OLO  SEQUENCE  WO»o 

-RETURN  WORO 

-NEW  SEQUENCE  WORD 


MAO  SELF  TEST 

This  MODULE  EXECUTES  EVERY  MINOR  CYCLE 

SET  W0J0  S CF  oUF.?E  TO  RESULT  OF  SELF  T.  ST  PROGRAM 
IF  WORJ  S INDICATES  A FAILURE 

. THEN 

. IF  FAILURE  RtCOVERASCE 

. . THEN 

. . CALL  APPROPRIATE  RECOVERY  POUTTNf 

. . SET  STATUS  WORTS  AHO  CONFIGURATION  ID  TO  INDICATE  NEW 

. . CONFIGURATE 

• . ELSE 

. . ATTEMPT  To  ACTIVATE  SHUTDOWN  M;  Co  AN  IS  w 

. ENOIF 

• ELSE 

. IF  NEW  MAJOR  CYCLF 
. . INCREMENT  MAJOR  CYCLE  NO. 

. . SET  MINOR  CYCLE  NO.  TO  0 

. ENOIF 

. SET  WORO  1 OF  BUF.29  TO  NOOE  TO.  MAJOR  CYCLF  NO,  MINOR  CYCLE  NO 
. INCREMENT  MINOR  CYCLE  NO. 

. COPY  STATUS  WORC  l INTO  WORO  Z OF  9UF.29 

. COPY  STATUS  WORO  2 INTO  WOFO  3 OF  9Ur_2R 

. SET  WORO  A OF  8UF.29  TO  CONFIGURATION  10 

. SET  WORO  6 OF  3UF.29  TO  LAST  WORD  A TRANSMITTED  FROM  8UF.29 

. StT  WORO  7 OF  8UF.29  TO  LAST  WORO  S RECEIVED  FROM  NOOE  90 

. SET  WORO  * OF  8UF.29  TO  A NEW  SEQUENCE  WO’  0 
. WRITE  8UF.29  TO  I.M. 

ENOIF 

END 


Figure  6-75.  Node  30  Self-Test  Function 
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6.6.4  Noae  90 
6.6.4. 1 General  Description 

Node  90  performs  two  major  functions.  It  controls  the  bus  by  means  of  the 
bus  controller  program  described  in  the  DAIS  Bus  Control  Specification,  and  it 
monitors  the  condition  of  the  system  by  means  of  the  self-test  messages  it  re- 
ceives every  minor  cycle. 

6.6.4.  2 I/O  Description 

In  addition  to  sending  out  the  I/O  inherent  in  the  bus  controller.  Node  90 

i 

sends  out  a self-test  message  to  Node  30  and  Node  70  every  minor  cycle.  It 
also  receives  self-test  messages  from  the  other  nodes  every  minor  cycle. 

These  messages  are  defined  in  Tables  6-15  and  6-16. 

6.6.4. 3 Software  Module  Description 

6. 6. 4.  3.1  Executive  Control  Processing.  Since  Node  90  is  an  AN/ AY K- 14 
computer,  assume  that  the  SDEX-M  executive  and  DAIS  bus  controller  software 
will  be  implemented. 

6.6.4.  3.2  Operational  Modules.  The  DAIS  bus  controller  is  the  only  opera- 
tional module  executed  by  Node  90. 

6.6. 4. 3.  3 Test  and  Reconfiguration.  Node  90  processes  all  incoming  self-test 
messages;  determines  if  a node  is  faulty;  and,  if  so,  institutes  reconfiguration 
efforts.  Figures  6-76  through  6-73  describe  this  process.  Node  90  also  per- 
forms a self-test  every  minor  cycle  and  sends  the  results  to  both  Node  30  and 
Node  70,  as  described  in  Figure  6-78. 
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TABLE  6-15.  NODE  90  INPUT  MESSAGES 


*** 

* 

* 

* 

♦ 

* 


SRC 

I ODE 

RCV 

SUB 

ADR 

WORDS 

PER 

SECOND 

PERIOD 

IN 

MSEC 

CYC 

CODE 

WORD 

COUNT 

21 

2 

■Pj 

n 

0 

3 

30 

4 

1 

1.1 

0 

8 

70 

5 

160 

50 

0 

3 

31 

8 

160 

50 

0 

8 

32 

9 

160 

50 

0 

8 

1 

TABLE  6-16.  NODE  90  OUTPUT  MESSAGES 


DEST. 

NODE 

■ 

I 

WORDS 

PER 

SECOND 

PERIOD 

IN 

MSEC 

CYC 

CODE 

WORD 

COUNT 

n 

1 

160 

50 

0 

8 

KH 

30 

0 

7 

KJ 

2 

160 

50 

0 

3 

■H 

1 

*** 

★ 

♦ 

* 
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Figures  6-76  through  6-73.  Node  90  Test  and  Reconfiguration  Function 
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HOOULE  NAME  ■ CONFIGURATION  MONITOR 


OATA  REQUIREO 


SELF  TEST  MESSAGES  FROM  ALL  OTHER  NOOES 
FIX  FILE  FROM  NOCE  A?  OR  NOOE  70 
TRACK  FILE  FRCM  NOOE  82  OR  NOOE  7 
SONOBOUT  FILE  FRCM  NOCE  82  OR  NOOE  70 
RECOVERY  PROGRAMS  FROM  MASS  MEMORY 

RECOVERY  OATA  ANO  TASK  PAPAMETER  PACKETS  FROM  MASS  MEMORY 


OATA  PROOUCED 


CONFIGURATION  MONITOR 

THIS  NOODLE  PROCESScS  THE  SELF  TtST  MESSAGt  FROM  c A CH  NOCE 
AND  OETERMINES  MHEt  hER  THAT  NOOF  MUST  ■'  SHUT  'OWN  ANO  ISOLATFO 
FROM  THE  SYSTEM.  IN  THIS  E'/ENT,  ThF  NODE  TS  ISOLATED  ANO  PR ESFT 
RECOVERY  PROGRAMS  ANO  OATA  APE  LOADET  FPOM  MASS  MEMORY. 

OYNAMIC  OATA  IS  LOACCO  FROM  NODE  82  0*  NODE  70. 

WHERE  TT  IS  REDUNCAMLV  STORE0. 

IPRCCESS  SELF  TEST  MESSAGES* 

{CALCULATE  CONFIGURATION  ICI 
IF  nfCOVEPY  MUST  9E  ATTEMPTED 
. IF  NOOE  81  HAS  NOT  FAILEO 
. . THEN 

. . seno  alert  to  operator 

. . ELSE 

. . SENO  ALERT  TO  CCU 

. EMOIF 

. INH 19 1 T all  MESSAGES  T 3 ANO  FROM  FAILED  NOOE 
. CASENTRY  FAILED  NODE 
. INOCE  70  RECOVER! 

. {NOOE  21  RECOVER! 

. INODE  JO  RECOVER! 

. INOOE  81  RECOVER! 

. INOOE  82  RECOVER! 

. S&U S RECOVER!  • 

E NOCASE 

ACTIVATE  COLO  START  INITIALIZATION 
ENOIF 


Figure  6-76 
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PROCESS  SELF  TEST  MESSAGES 


THIS  NOOULt  CHECKS  THE  CONTENTS  OF  Tht  SELF  TEST  MESSAGES  INPUT 
FROM  EACH  NOOE  EVERT  MINOR  CVCLF.  IT  RETURNS  A BINARY  PLAG  VECTOR 
INDICATING  WHICH  NO  CT  S HAVE  FAILED. 


SET  NOOE.INOEX  TO  1 

00 WHILE  NOOE.INCEX  L£  NUMaER.OF.NOOES 

. SEPARATE  FIRST  WORO  OF  SELF  TEST  MESSAGE  FROH.  NOOE  (NOCE_  INCEX  ) 

. INTO  NOOE. 10.  MAJOR.CTCLE.NO,  ANO  MI  NOR.LT  CLE.NO 
. IF  ALL  CORRECT 
. . THEN 

. . CHECK  THAT  WOPO  A EQ  CONF IGUR AT  ION. I D 

. . IF  CORRECT 

. . . THEN 

. . . CHECK  THAT  IFPM  RESULTS  ARE  NORMAL 

. . . IF  CORRECT 

. . . . THEN 

. . . . CHECK  THAT  WORO  6 iO  LAST  WORO  8 TRANSMITTED  FROM  NOOE 

. . . . IF  CORRECT 

THEN 

CHECK  THAT  WORD  7 EQ  lAST  WORD  8 TRANSMITTED  TO  NOOE 

IF  CORRECT 

• • « • • .THEN 

SET  FAlLEC.NOOE.FLAGfNOOE.TNuEYI  TO  1 

ELSE 

SAVE  SELC_T  ES  T MESSAGE  IN  PRESET  MFMOFW  LOCATIONS 

SET  FAILED. NOOE.FLAGI NOOE. INDEX!  TO  1 


ENOIF 

ELSE 

SET  FAILEC. NODE.  FLAG  INOnt.INUi  X»  TO  1 

. . . . ENOIF 

. . . . ELSE 

. . . . SET  FAILEO.NCOE.FLAGINOOt.tNOEX » TO  1 

. . . ENOIF 

. . . ELSE 

. . . SET  FAILED. NOOE. FLAGINOOE. INDEX t To  1 

. . ENOIF 

. . ELSE 

. . SET  FAILEO.NOCE.FLAGINOOE  INjExI  TO  t 

. ENOIF 

. IF  FAI  LED.  NO  CE.FLAGCNOOE  .INDEX!  EO  t 

. . SAVE  SELF  TEST  MESSAGE  IN  PRESET  MEMORY  LOCATIONS 

. ENOIF 
ENOOO 


ENO 


Figure  6-77 


1 


NADO  79161-40 


NO0ULE  NAME  I CONTROLLER  TEST  MESSAGE 


M 

DATA  REQUIRED 


RESULTS  CF  SELF  TEST  PROGRAM 
2 STATUS  WOROS 

OLO  SEQUENCE  MORO  (SEQUENCE  MORO  LAST  TRANSMITTED! 
LAST  RETURN  MORC  INPUT  FROM  NODES  DO 


OATA  PROOUCEO 


8 WORD  SELF  TEST  MESSAGE  IbUF.’S) 

-NOOE  10.  MAJOR  CTCLE  NO,  MINOR  CYCLE  NO 
! -STATUS  MORO  1 

-STATUS  MORO  Z 

-CONFIGURATI CN  ICENT 

-RESULTS  OF  SELF  TEST  PROGRAM 

-OLO  SEQUENCE  MORC 

-RETURN  MORO 

-NEM  SEQUENCE  MORC 


CONTROLLER  TEST  MESSAGE 

THIS  MODULE  EXECUTES  EVERT  MINOR  CYCLE 


i 


SET  hPRO  3 CF  3UF_?o  to  pg-JULT  OF  -FLF  'EST  Ponf.RAM 
IF  MORC  5 INDICATES  A FAILURE 

. THEN 

. IF  FAILURE  REC0VERA3LE 
. . THEN 

. . call  APPROPRIATE  RECOVERY  AOUT'Nc. 

. . SET  STATUS  MORES  ANO  CONFIGURATION  TC  TO  TNOICATE  NEM 

. . CONFIGURATION 

. . ELSE 

. . ATTEMPT  TO  ACTIVATE  SHUTOOMN  mtCmANTSM 

. ENOIF 
. ELSE 

. IF  NEM  MAJOP  CYCLE 
. . INCREMENT  MAJOR  CYCLE  NO. 

. . SET  MINOR  CYCLE  NO.  TO  0 

. ENOIF 

. SET  MORO  l OF  PUF.ZR  TO  NOOE  10.  MAJOR  CYCLE  NO,  MINOR  CYCLE  NO 
. INCREMENT  MINOR  CYCLE  NO. 

. COPY  STATUS  MORO  l INTO  MORO  Z OF  3UF_2? 

. COPY  STATUS  MORO  ? INTO  MORO  5 OF  3UF.2R 

. SET  MORP  4 OF  3UF.Z9  TO  CONFIGURATION  ID 

. SET  MOPD  6 OF  3UF.Z9  TO  LAST  MO-  0 8 TRANSMITTED  FROM  eUF.ZS 

. SET  MORO  7 OF  BUF_J9  TO  LAST  MORO  d RECEIVED  FROM  NOOE  30 

. SET  MORO  8 OF  3UF.Z9  TO  A ME  M SEQUENCE  MO5  0 
. WRITE  BUF.Z9  TO  NODE  30 
. WRITE  3UF.Z9  TO  NOOE  70 
ENOIF 

ENO 


Figure  6-78 
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6.6.5  Node  21 

6. 6. 5.1  General  Description 

Node  21  simulates  those  peripherals  used  by  the  other  nodes  and  is  con- 
nected to  the  main  system  bus.  Specifically,  the  MAD,  ESM,  and  radar  pe- 
ripherals are  simulated.  (Radar  and  ESM  data  are  not  presently  used  by  any 
node,  but  short-term  plans  include  the  development  of  a radar/ESM  contact 
correlation  algorithm  for  use  by  an  AN/AYK-14;  therefore,  these  peripherals 
have  been  included  in  the  simulation,  with  Node  30  chosen  as  the  destination  of 
the  simulated  data. 

Node  21  will  also  contain  the  JTIDS  simulation  currently  being  developed 
for  BASIC  by  503  division. 

Finally,  Node  21  will  simulate  the  reconfiguration  bulk  store  and  will  trans- 
mit reconfiguration  programs  over  the  bus,  as  required. 

6. 6. 5. 2 I/O  Description 

The  input  and  output  messages  making  up  the  Node  21  interface  are  shown 
in  Tables  6-17  and  6-13,  respectively.  An  asynchronous  command  output  has 
no  present  use  but  has  been  included  for  flexibility. 

6. 6. 5.  3 Software  Functional  Description 

6. 6. 5. 3.1  Control  Modules.  The  control  module  requirements  for  Node  21 
are  identical  to  those  of  Node  70.  Figures  6-79  through  6-63  describe  these 
software  executive  functions. 

6. 6.  a.  3.  2 Operational  Modules.  Node  21  simply  outputs  preset  data  according 
to  Table  6-18  and  accepts  whatever  data  is  sent  to  it.  This  node  executes  a 
limited  number  of  commands  from  Node  32  to  Node  90.  Figures  6-84  through 
6-88  describe  these  procedures. 

6.6.5. 3. 3 Test  and  Reconfiguration  Modules.  Node  21  outputs  a self-test 
message  every  minor  cycle  and  also  responds  to  a read  block  command  from 
Node  90.  This  command  will  cause  a reconfiguration  program  to  be  read  from 
bulk  storage  and  transmitted  over  the  bus.  This  process  is  described  by  Figures 
6-89  and  6-90. 
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MOOULE  NAnE • INITIALIZE  peripheral  simulation 


DATA  REQUIRED 


NONE 


DATA  PROOUCED 


NONE 

INITIALIZE  PERIPHERAL  SIMULATION 

THIS  PROCESS  IS  ACTUATED  9Y  A POWER  ON  CONOITION 

(IF  POSSIBLE).  If  LOAOS  PROGRAMS  AND  PRESET  DATA 

FROM  THE  FLOPPY  DISK  ANO  SETS  THE  NECESSARY  INITIAL 

VALUES.  IT  ALSO  INITIALIZES  THE  INTERRUPT  STRUCTURE 

ANO  SCHEOULES  THE  OUTPUT  PROCESSING  ANO  SELF  TEST  MODULES. 

FINALLY,  IT  CALLS  T HE  "DISPATCH"  MODULE 

TO  INITIATE  PROCESSING. 

END 


Figure  6-79 


MOOULE  NAME  * INTERRUPT  HANDLE* 

DATA  REQUIRED 

TYPE  OF  EVENT  (EXTERNAL  OR  BUS  INPUT) 

OATA  PROOUCED 


NONE 

INTERRUPT  HANOLER 

THIS  FUNCTION  SAVES  THE  STATE  OF  THE  MACHINE  ANO  TRANSFERS 
CONTROL  TO  THE  PROPER  INTERRUPT  RESPONSE  MOOULE 


LOCK  OUT  ALL  FURTHER  INTERRUPTS 
SAVE  PROGRAM  CTR 
SAVE  STACK  POINTERS 
SAVE  REGISTER  CONTENTS 

CASE  INTERRUPT  TYPF  (EXTERNAL  OR  BUS  INPUT) 
. "EXTERNAL  INTERRUPT" 

. "READ" 

ENOCASE 

RESTORE  MACHINE  STATE 
ENABLE  INTERRUPTS 
TRANSFER  TO  PROGRAM  CTR 

ENO 


Figure  6-80 
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MODULE  NAME  I DISPATCH 

DATA  REQUIRED 


INI T FLAG  (INITIALLT  PRESET  TO  01 

NEW_NINOR.CYCLE.FLAG 

PERIODIC  PROGRAM  PARAMETERS 

-STACK.POINTER 

-DEPTH_0F_STAC< 


DATA  PROOUCEO 


NONE 


DISPATCH 

THIS  PROCESS  CALLS  ALL  THE  PERIODIC  PROCESSES 
EKEC'JTEO  DT  THE  l -P.  IT  IS  THE  LOWEST  PRIORITY 
PROCESS  AND  IS  PRE-EMPTED  BY  ALL  INTERRUPTS. 

IT  REPEATS  FOR  EACH  MINOR  CYCLE.  PERIODIC  PROCESS 
ARE  PRIORITISED  3Y  THEIR  POSITION  IN  THE  STACK. 


OOWHILE  »OWER  IS  ON 

. IF  NEW.MINOR.CYCLE.FLAG  EO  1 AND  INIT.FLAG  EO  l 
. . THEN 

. . SET  NEW.MINOR.CYCLE.FLAG  TO  D 

. . DOWHILE  STACR  SOT  EMPTY 

. . . INITIALIZE  MACHINE  STATE  FOR  EACH  PERIODIC  PROCESS. 
. . . EACH  STACR  ENIRY  POINTS  TO  A BUFFER  AREA  CONTAINING 
. . . INITIALIZATION  PARAMETERS. 

. . . CALL  PROCESS  REPRESENTED  BT  STACK  ENTRY. 

. . ENOOO 

. END  IF 

ENOOO 

END 


Figure  6-81 
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DATA  REQUIRED 


INPUT  message  I ASSUME D TO  BE  LOCATED  IN  I.N.  BUFFER! 
IABLE  OF  MEMORT  BUFFER  LOCATIONS  FOR  EACH  RCV  ADRESS. 
TABLE  OF  BUFFER  LENGTHS  FOR  EACH  RCV  ADORESS. 

INPUT  MESSAGE  RCV  ADORESS 


DATA  PRODUCED 


INPUT  MESSAGE  IN  RCV  ADRESS  SUFFER 


READ 

THIS  MODULE  INPUTS  MESSAGES  FROM  THE  INTERFACE  MODULE 

IF  RCV  AOORESS  EQ  30 
. THEN 

. INPUT  MESSAGE  TO  RCV  AOR  30 
. ACKNOWLEDGE  INPUT 
. CALL  "COMMAND  PROCESSING"  MOOULE 
. ELSE 

. transfer  message  to  appropriate  input  3UFEER 

. ACKNOWLEDGE  INPUT 
ENOIF 

ENO 


Figure  6-52 


MOOULE  NAME!  WRITE 

OATA  REQUIRED 


KMT  MESSAGE  AOORESS 

TABLE  DF  BUFFER  LOCATIONS  FOR  EACH  TNT  AOORESS 
TABLE  OF  BUFFER  LENGTHS  FOR  EACH  TNT  AOORESS 


OATA  PRODUCED 


OUTPUT  MESSAGE  TO  INTERFACE  MODULE 
WRITE 

This  FUNCTION  OUTPUTS  the  spec  if ieo  message 
TO  THE  INTERFACE  MOOULE.  IT  WAITS  FOR  AN  ACKNOWLEDGE 
FOR  A SPECIFIED  PER  100  OF  TIME.  NONE  OCCURING.  AN 
ERROR  CONDITION  IS  NOTED  IN  THE  STATUS  WORD. 

ENO 


Figure  6-83 
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NODULE  MAKE • PERIPHERAL  OUTPUT  SIMULATION 


DATA  REQUIRED 


PRESET  DATA  FOR  OUTPUT  SUFFERS 

-OUTPUT  SUFFERS  DU  NOT  CHANGE  IF  OATA  IS  STATIC. 

-IF  OATA  IS  VARIED  IN  A PREDEFINED  MANNER. 

-A  SEQUENCE  OF  "RESET  3L0CKS  IS  DEFINEO 
-WHICH  CAN  BE  ACCESSED  USING  A SEQUENCE  NUMBER 
-CONTAINED  IN  3UF.SE3.  WHICH  IS  A VECTOR  CONTAINING 
-THE  CURRENT  SEQUENCE  NUMBER  FOR  EACH  BUFFER. 

-THE  LENGTH  OF  EACH  SEQUENCE  IS  CONTAINED  IN 
-THE  VECTOR  MAX.BJF.SEO 


DATA  PRODUCED 


UPDATES  OF  OUTPUT  BUFFERS  FOR  TRANSMISSION 

3UF.2  MMT  SUB  ADDRESS  l-  iZ  WCJROS  I 

3UF  _ 3 -32  WOS 

BUF.a-32  WDS 

BjF.5-32  WOS 

3 JF  _S- 3 2 WOS 

3UF.7-1B  WOS 

BUF.3-16  WOS 

BUF.14-3  WOS 

BUF.17-8  WOS 

BUF.20-2B  WDS 

3UF.2A-3  WDS 


Figure  6-84a 
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PERIPHERAL  OUTPUT  SIMULATION 

THIS  MODULE  EXECUTES  EVERY  MINOR  CYCLE 

INCREMENT  CYCLE.COOE_l.FLAG 
INC R EME NT. CYCLE .CODE. 2.F LAG 
INCREMENT  CYCLE .CDOE.A. FLAG 
IF  PER _I MI T.F L AG  1 2 I EO  1 

. IF  3UF.Z  MUST  BE  VARIED  ACCORDING  TO  A PRESET  SEQUENCE 

. . TRANSFER  3Z  WORDS  TU  BUF.Z  FROM  AREA  INOICATEO  BY  BUF.SEQTZI 

. . INCREMENT  BUF.SEQTZI 

. . IF  BUF.SEQTZI  GT  M A X.BUF .S EQ ( Z I 

. . . SET  BUF.SEQTZI  TO  0 

. . ENDIF 

. . WRITE  BUF.Z  TO  INTERFACE  MODULE 

. ENDIF 

ENOIF 

IF  PER.INIT.FLAGT3 I EQ  1 

. IF  3UF.3  MUST  BE  VARIED  ACCORDING  TO  A PRESET  SEQUENCE 
. . TRANSFER  32  WOROS  TO  8UF.3  FROM  AREA  INOICATEO  BY  BUF.SEO ( 3 1 

. . INCREMENT  BUF.SE3T3I 

. . IF  BUF.5EOT31  GT  M A X .BUF .S EQ I 3 I 

. . . SET  BUF.SEQT3I  TO  0 ' 

. . ENDIF 

. . WRITE  BUF.3  TO  INTERFACE  MOOULE 

. ENOIF 

ENOIF 

IF  PER.INIT.FLAGT4I  EQ  l 

. IF  3UF.'.  MUST  BE  VARIED  ACCORDING  TO  A PRESET  SEQUENCE 

. . TRANSFER  32  WORDS  TO  BUF.A  FROM  AREA  INDICATED  BY  BUF  SEQIMI 

. . INCREMENT  3JF.SEQT  Al 

. . IF  3UF.SEQTEI  GT  MAX.BUF.SEOl  A I 

. . . SET  BUF.SEQTEI  TO  0 

. . ENDIF 

. . WRITE  BJF.E  TO  INTERFACE  MODULE 

. ENOIF 
ENDIF 

IF  PER.INIT.FLAGIM I EO  l 

. IF  3JF.S  MUST  3 E VARIED  ACCORDING  TO  A PRESET  SEQUENCE 
. . TRANSFER  32  WORDS  TO  3UF.S  FROM  AREA  INDICATED  BY  BUF.SEQISI 

. . increment  bjf.seotsi 

. . IF  BUF.SEQT5I  GT  M AX .BUF _S E 0 ( 5 I 

. . . SET  BUF.SEQISl  TO  0 

. . ENOIF 

. . WRITE  3UF.5  TO  INTERFACE  MOOULE 

. ENOIF 
ENOIF 

IF  PER.INIT.FL  AGT  5 I E O l 
. IF  CYCLE. CODF.I.FLAG  EQ  Z 
. . SET  CYCLE. COOE.l. FLAG  TO  3 

. . IF  BUF.h  MUST  BE  VARIED  ACCORDING  TO  A PRESET  SEQUENCE 

. . . TRANSFER  3Z  WOROS  TO  BJF.i  FROM  AREA  INOICATEO  BY  BUF.SEQTGl 

. . . INCREMENT  BUF.SEO  t b 1 

• . . IF  BUF.SEOTBI  GT  MAX  BJF.SEQTM 

. . . . SET  BUF.SEOTNI  TO  0 

. . . ENDIF 

. . . WRITE  3UF.6  TO  INTEPFACE  MOOULE 

. . ENOIF 

. ENOIF 
ENOIF 

IF  PER.INIT.FLAGT7I  EQ  l 


Figure  6 -84b 
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. IF  CYCLE. COOE.2. FLAG  EO  4 
. . SET  CYCLE.CODE_2.FLAG  TO  0 

. . IF  BUF.7  MUST  3E  VARIED  ACCORDING  TO  A PRESET  SEQUENCE 

. . . TRANSFER  16  WOROS  TO  BUF.7  FROM  AREA  INDICATED  BT  BUF.SEQ(7I 

. . . INCREMENT  BJF_SEQ17> 

. . . IF  BU  F.SE  0 ( 7 I GT  MAX.BJF  SE0I7) 

. . . . SET  BUF.SEQi 71  TO  0 

. . . END  IF 

. . . WRITE  BUF.7  TO  INTERFACE  MODULE 

. . ENOIF 

. ENOIF 
ENOIF 

IF  PER.INIT.FLAGIBI  EO  1 

. IF  CYCLE. CODE .2 .FLAG  EO  A 

. . SET  CYCLE. CODE. 2.FLAG  TO  0 

. . IF  BUF.8  MUST  BE  VARIEO  ACCORDING  TO  A PRESET  SEQUENCE 

. . . TRANSFER  30  WOROS  TO  BUF.8  FROM  AREA  INDICATED  BT  8UF.SEQI8J 

. . . INCREMENT  BUF.SEQ(B) 

. . . IF  BUF.SEQ(S)  GT  M A X.B J F . SE 0 I 8 I 

. . . . SET  BUF.SEQI 81  TO  0 

. . . ENOIF 

. . . WRITE  BUF.8  TO  INTERFACE  MODULE 

. . ENOIF  — — 

. ENOIF 
ENOIF 

IF  PER_tNIT.Fl AGI 1* ) EQ  1 “ 

. IF  3UF.lt  MUST  BE  VARIED  ACCORDING  TO  A PRESET  SEQUENCE 
. . TRANSFER  3 WOROS  TO  8UF.lt  FROM  AREA  INOICATEO  BY  BUF.SEQIltl 

. . INCREMENT  B'JF.SEQIltl 

. . IF  BUF.SEOIlt)  G T MA X. BUF. S E 0 II  t ) 

. . . SET  BUF.SEQIltl  TO  0 

. . ENOIF 

. . WRITE  BUF.lt  TO  INTERFACE  MODULE 

. ENOIF 
ENOIF 

IF  PER. INI T.FLAGI 1 7 I EQ  1 
. IF  CYCLE. CODE_t.Fl  AG  EQ  16 
. . SET  CYCLE .COOE.t.FLAG  TO  0 

. . IF  BUF.  1 7 MUST  be  VARIED  ACCORDING  TO  A PRESET  SEOUENCE 

. . . TRANSFER  9 WORDS  TO  BUF. 17  FROM  AREA  INOICATEO  3Y  BUF.SEQI  171 

. . . INCREMENT  BUF.SEQI 171 

. . . IF  BUF.SEQI  171  GT  M A X .BiJF  _S  E Q I 1 7 I 

. . . . SET  BUF.SEQI 171  TO  0 

. . . ENOIF 

. . . WRITE  BUF. 17  TO  INTERFACE  MODULE 

. . ENOIF 

. ENOIF 
ENOIF 

IF  PER.INII.FLAGI20I  EQ  l 
. IF  CYC LE.CtlOE_7.FLAG  EO  t 
. . SET  CYCLE. COOE. 2. FLAG  TO  0 

. . IF  BUF. 20  MUST  BE  VARIEO  ACCORDING  TO  A PRESET  SEQUENCE 

. . . TRANSFER  2 1 WORDS  TO  BUF. 20  FROM  AREA  INOICATEO  BY  BUF.SE0I20I 

. . . INCREMENT  BUF  _S  E 0 I 2 0 I 

. . . IF  BUF.SE  Q I 20  I GT  MAX .BUF _S E 0 I 20  I 

. . . . SET  BUF.SEQI 20)  TO  0 

. . . ENOIF 

. . . WRITE  BUF .20  TO  INTERFACE  MOOULE 

. . ENOIF 

. ENOIF 
ENOIF 

IF  PER.lNIT.FLAGIRt)  EQ  1 

. IF  BUF. 24  MU5T  OE  VARIEO  ACCORDING  TO  A PRESET  SEOUENCE 
; ; tRANSFER  J WORDS  TO  CUT. 24  FROM  AREA  INDICATED  3Y  OUF.SEOICt) 


Figure  6-84c 
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. . INCREMENT  3UF_SEQI2<>> 

. . IF  8UF_SEOT2AI  G I MAX_8UF_SEOT2A  I 

. . . SET  BUF.SEOIZAI  TO  0 

. . ENOIF 

. . URITE  BUF.2S  TO  INTERFACE  NODULE 

. ENOIF 

ENOIF 

END 


Figure  6-84d 


NODULE  NANEI  COMMAND  PROCESSING 


DATA  REQUIRED 

input  command  id  and  data  kords  from  r;v  address  30  input  buffer 
DATA  PRODUCED 


NONE 


COMMANO  processing 

this  nodule  interprets  the  cummano  io  and  calls  the  appropriate 

SUBROUTINE  TO  EXECUTE  THE  COMMAND 

CASE  COMMAND  ID 
. TCOMN  INITi 
. SNEU  MINOR  CTCLEt 
. TREAD  BLOCKS 
. TCJMM  TERMS 
ENDCASE 

END 


Figure  6-85 
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set  init.flag  ro  1 

fuhn  32  ii r input  oata  woro  fron  data  words  i and  2 of  input  buffer  30 
set  i n i 
OOWHILE  I LE  32 

. SET  PER. INIT. FLAG! II  TO  9ITII)  OF  INPUT  DATA  WORD 

. INCREMENT  I 

ENOOO 

ENO 


Figure  6-86 


NEW  NINOR  CYCLE 

SET  NEW. NINQRCYCIE. FLAG  TO  1 
END 


Figure  G-37 


CONN  TERN 

SET  INIT. FLAG  TO  3 
END 

Figure  6-88 
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Figures  6-39  and  6-90.  Node  21  Test  and  Reconfiguration  Function 
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READ  BLOCK 

SET  ADR  TO  FIRST  WORD  AOORESS  OF  BLOCK  AS  SPECIFIED  BE  INPUT  DATA  WORD 

SET  3LOCK. LENGTH  TO  VALUE  SPECIFIED  BY  INPUT  WORO 

SET  DESTINATION  NODE  ACCORDING  TO  INPUT  DATA 

SET  I TO  1 

SET  J TO  1 

SET  DONE  TO  0 

OOWHILE  I LE  BLOCK. LENGTH  AND  DONE  EO  0 
. SET  J TO  t 

. OOWHILE  J LE  3?  AND  DONE  E9  0 

. . TRANSFER  MEMORY  WORO(AOR)  TO  XMT  SUB  ADDRESS  30  . WORD  J 

. . INCREMENT  I 

. . INCREMENT  J 

. . INCREMENT  ADR 

. . IF  I ST  BLOCK.LENGTH 

. . . SET  DONE  TO  l 

. . ENOIF 

. ENDDO 

. WRITE  XMT  SU  3 AOORESS  30  BUFFER  TO  DESTINATION  NODE 
ENDDO 

ENO 


Figure  6-S9 
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MOOULE  NAME  PERIPHERAL  SIMULATION  SELF  TEST 


DATA  REQUIRED 


RESULTS  OF  SELF  TEST  PROGRAM 
2 STATUS  WOROS 

OLO  SEQUENCE  WORO  ISEOUENCE  WORD  LAST  TRANSMITTED) 
LAST  RETURN  WORO  INPUT  FROM  NOOE  90 


DATA  PROOUCED 


8 WORO  SELF  TEST  MESSAGE  t3UF_29l 

-NODE  10.  MAJOR  CYCLE  NO.  MINOR  CYCLE  NO 

-STATUS  WORD  1 

-STATUS  WORO  Z 

-CONFIGURATION  IDENT 

-RESULTS  OF  SELF  TEST  PROGRAM 

-OLO  SEQUENCE  WORO 

-RETURN  WORO 

-NEW  SEQUENCE  WORO 


PERIPHERAL  SIMULATION  SELF  TEST 

THIS  MODULE  EXECUTES  E VE  ® Y MINOR  CYCLE 

SET  WORD  5 OF  B'JF.29  TO  RESULT  IF  SELF  TEST  PROGRAM 
IF  WORO  > INDICATES  \ FAILURE 

. THEN 

. IF  FAILURE  recoverable 

. THEN 

. . CALL  APPROPRIATE  RECOVERY  ROUTINE 

. . SET  STATUS  WORDS  ANO  CONFIGURATION  10  TO  INOICATE  NEW 

. . CONFIGURATION 

. . ELSE 

. . ATTEMPT  TO  ACTIVATE  SHUTDOWN  MECHANISM 

. ENOIF 
. ELSE 

. IF  NEW  MAJOR  CTCLE 
. . INCREMENT  MAJOR  CYCLE  NQ. 

. . SET  MINOR  CYCLE  NO.  TO  0 

. ENOIF 

. SET  WORD  1 OF  BJF.29  TO  NOOE  ID.  MAJOR  CYCLE  NO.  MINOR  CYCLE  NO 
. INCREMENT  MINOR  CYCLE  NO. 

. COPY  STATUS  WORO  l INTO  WORO  Z OF  3UF.29 

. COPY  STATUS  WORD  Z INTO  WORO  3 OF  9UF.29 

. SET  WORO  A OF  9UF.29  TO  CONFIGURATION  ID 

. SET  W'JRO  8 OF  3 IF.  '9  TO  LAST  WORD  3 TRANSMITTED  FRMN  3UF.29 

. SET  »URD  7 OF  8UF.29  TO  LAST  WORO  3 RECEIVED  FROM  NODE  90 

. SET  WORO  9 OF  3UF  29  TO  A NEW  SEQUENCE  WORO 
. WRITE  SUE  29  TO  I.N. 

END  1 F 

END 


Figure  6-90 
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